VBA Workbook_Open dans Excel — exécuter une macro automatiquement à l'ouverture du fichier (et où le code doit résider)

TL;DR — Workbook_Open est une procédure d'événement : Excel l'appelle pour vous à l'instant où le fichier finit de s'ouvrir, si bien qu'une macro peut s'exécuter d'elle-même, sans bouton et sans action de l'utilisateur. Deux choses font toute la différence. D'abord, elle doit résider dans l'objet ThisWorkbook, pas dans un Module standard — collez-la dans Module1 et elle ne se déclenchera tout simplement jamais. Ensuite, elle ne s'exécute que si les macros sont activées et que le fichier est un classeur prenant en charge les macros (.xlsm/.xlsb) ; si l'utilisateur l'ouvre avec les macros bloquées, rien ne se passe et aucune erreur ne s'affiche.

' Ce code réside dans l'objet ThisWorkbook (double-cliquez sur « ThisWorkbook »
' dans l'Explorateur de projets — PAS dans Module1).
Private Sub Workbook_Open()
    Worksheets("Dashboard").Activate
    Range("A1").Select
    MsgBox "De retour — dernière actualisation des données le " & Format(Now, "dd mmm, hh:nn")
End Sub

La plupart des macros attendent un bouton, un raccourci ou la boîte de dialogue Macros. Une macro d'événement est différente : vous ne l'appelez jamais — vous l'enregistrez, et Excel l'exécute quand quelque chose se produit. Workbook_Open est le premier événement que la plupart des gens rencontrent, car « faire ceci à chaque ouverture du fichier » est un besoin si courant : sauter au tableau de bord, actualiser une requête, préparer l'interface, horodater un journal d'ouverture. C'est aussi l'événement qu'on n'arrive le plus souvent pas à déclencher — presque toujours pour l'une des deux raisons que cet article rend impossibles à manquer.

Ce que vous allez apprendre

• Le modèle mental — un gestionnaire d'événement que vous enregistrez, et non une macro que vous exécutez
• La règle unique qui décide de tout — le code doit résider dans ThisWorkbook
• Pourquoi il ne s'exécute jamais en silence — la sécurité des macros et le mauvais format de fichier
• Workbook_Open face à l'ancien Auto_Open, et lequel utiliser
• Pourquoi le code d'événement doit être rapide et à l'épreuve des plantages — il accueille l'utilisateur à chaque ouverture

Le modèle mental : un gestionnaire d'événement que vous enregistrez, pas une macro que vous exécutez

Une macro normale est un verbe que vous invoquez : vous appuyez sur un bouton et Sub RefreshData s'exécute. Une procédure d'événement est l'inverse — vous l'écrivez une fois, la placez à un endroit précis avec un nom exact, et c'est ensuite Excel qui décide quand l'appeler. Vous n'exécutez pas Workbook_Open ; vous promettez à Excel « voici quoi faire quand ce classeur s'ouvre », et Excel tient cette promesse à votre place.

Cela renverse la façon de penser « où placer ce code ». Pour une macro normale, l'emplacement importe peu. Pour un événement, l'emplacement est l'enregistrement. Excel cherche Workbook_Open à un seul endroit — le module de code propre au classeur, appelé ThisWorkbook — et nulle part ailleurs. Le nom et l'endroit forment ensemble tout le contrat.

La règle qui décide de tout : le code doit résider dans ThisWorkbook

C'est la première raison pour laquelle un Workbook_Open « ne fonctionne pas » : le code a été collé dans un module standard. Workbook_Open est un membre de l'objet classeur, donc son gestionnaire doit résider dans le module de code du classeur — ThisWorkbook — pas dans Module1.

Explorateur de projets (Ctrl+R dans l'éditeur VBA)
 └─ VBAProject (VotreFichier.xlsm)
     ├─ Microsoft Excel Objets
     │   ├─ Sheet1 (Sheet1)      ← les événements de feuille vont ici
     │   └─ ThisWorkbook         ← Workbook_Open va ICI (double-cliquez dessus)
     └─ Modules
         └─ Module1              ← un Workbook_Open ici ne se déclenche JAMAIS

Il existe un moyen rapide d'obtenir le squelette correct à chaque fois : ouvrez le volet de code de ThisWorkbook, choisissez Workbook dans la liste déroulante de gauche (Objet), puis Open dans celle de droite (Procédure). Excel écrit la signature exacte à votre place :

Private Sub Workbook_Open()

End Sub

La signature est figée. C'est Private Sub Workbook_Open() — aucun argument, orthographié exactement ainsi, dans ThisWorkbook. Renommez-la, ajoutez un paramètre ou déplacez-la, et elle cesse d'être le gestionnaire d'événement pour devenir un Sub ordinaire (jamais appelé). La règle : si une macro d'ouverture automatique refuse de se déclencher, vérifiez d'abord son emplacement — 9 fois sur 10, elle est dans un Module au lieu de ThisWorkbook.

La règle du « il ne s'exécute jamais en silence » : les macros doivent être activées

Même au bon endroit, Workbook_Open ne s'exécute que si Excel est autorisé à exécuter des macros — et quand il ne l'est pas, il n'y a ni avertissement ni erreur. Trois choses le désactivent discrètement :

• Le fichier ne prend pas en charge les macros. Le VBA ne survit que dans un .xlsm ou un .xlsb. Enregistrez un classeur contenant du code en simple .xlsx et Excel supprime toutes les macros — y compris Workbook_Open — avec une simple invite au passage. L'événement disparaît, tout bonnement.
• Les macros sont désactivées par la sécurité. Si l'utilisateur ouvre le fichier et le laisse en mode protégé, ou passe la bannière « Activer le contenu » sans rien activer, les macros ne s'exécutent pas, donc l'événement ne se déclenche pas.
• Les événements sont désactivés au niveau de l'application. Si un code antérieur a défini Application.EnableEvents = False sans jamais le rétablir, les événements de classeur et de feuille restent supprimés pendant toute la session.

La leçon de conception compte : ne faites jamais dépendre l'exactitude des données du seul Workbook_Open. Il est parfait pour le confort — sauter à une feuille, actualiser une vue — mais si un utilisateur ouvre le fichier avec les macros désactivées, votre code « qui s'exécute toujours » ne l'a pas fait. Considérez-le comme un plus qui améliore l'expérience, pas comme une garantie. (Si votre objectif est simplement d'aider les utilisateurs à franchir la bannière de sécurité, voyez comment activer les macros dans Excel.)

Workbook_Open contre Auto_Open : utilisez l'événement, pas la relique

Vous verrez deux façons d'exécuter du code à l'ouverture, et ce ne sont pas la même chose :

• Auto_Open est le mécanisme hérité (de l'époque Excel 5/95). C'est un simple Sub Auto_Open() qui réside dans un Module standard. Il fonctionne encore par souci de rétrocompatibilité, mais c'est une relique.
• Workbook_Open est l'événement moderne, qui réside dans ThisWorkbook.

Leurs différences peuvent faire mal :

À retenir : si une autre macro ouvre votre fichier avec Workbooks.Open "Report.xlsm", Workbook_Open se déclenche mais pas Auto_Open (à moins d'appeler explicitement wb.RunAutoMacros xlAutoOpen). Cette seule différence explique pourquoi les chaînes automatisées cassent avec Auto_Open. Écrivez Workbook_Open ; ne recourez à Auto_Open que pour maintenir de très vieux fichiers.

La règle qui évite de gâcher chaque ouverture : soyez rapide et à l'épreuve des plantages

Workbook_Open s'exécute avant que l'utilisateur ne puisse rien faire — donc quoi qu'il fasse, l'utilisateur le vit comme « le temps que met le fichier à s'ouvrir » et « si le fichier s'ouvre proprement ». Deux habitudes le maintiennent courtois :

Private Sub Workbook_Open()
    On Error GoTo Fail                 ' ne jamais laisser l'ouverture planter au nez de l'utilisateur
    Application.ScreenUpdating = False

    Worksheets("Dashboard").Activate
    Range("A1").Select

    Application.ScreenUpdating = True
    Exit Sub
Fail:
    Application.ScreenUpdating = True   ' toujours rétablir l'état, même en cas d'erreur
    MsgBox "Démarrage ignoré : " & Err.Description, vbExclamation
End Sub

• Enveloppez-le toujours dans une gestion d'erreurs. Une erreur non gérée ici jette une erreur VBA brute au visage de l'utilisateur dès qu'il ouvre le fichier, et peut laisser des réglages comme ScreenUpdating ou EnableEvents désactivés. Rétablissez l'état dans le gestionnaire. (C'est la même discipline que celle abordée dans VBA On Error.)
• Gardez le gros du travail à l'écart, ou rendez-le visible. Une requête lente ou une grosse boucle dans Workbook_Open ressemble exactement à un fichier figé. Si le travail est inévitable, affichez un message d'état ou déportez-le derrière un bouton que l'utilisateur choisit d'actionner.

Workbook_Open fait partie de toute une famille d'événements de classeur — Workbook_BeforeClose, Workbook_BeforeSave, Workbook_SheetChange — qui résident tous dans ThisWorkbook. Ses cousins au niveau de la feuille réagissent à ce qui se passe à l'intérieur d'une feuille : Worksheet_Change quand une cellule est modifiée, et Worksheet_SelectionChange quand le curseur se déplace.

Comment ExcelMaster aide

Mettre en place Workbook_Open est un petit rituel aux arêtes vives : le bon objet, le nom exact, un fichier prenant en charge les macros, la gestion d'erreurs, ne pas bloquer l'ouverture. Ratez-en un seul et le symptôme est le même « il ne s'est rien passé », aussi peu utile qu'à chaque fois.

ExcelMaster vous laisse décrire le résultat à la place. Dites « à chaque ouverture de ce fichier, saute à la feuille Dashboard et actualise le tableau croisé dynamique », et il écrit le gestionnaire, le place dans ThisWorkbook, et l'enveloppe pour qu'un échec ne fasse pas planter l'ouverture. Le fichier reste le vôtre et vous pouvez en lire chaque ligne — mais vous vous épargnez le moment où une macro refuse en silence de s'exécuter parce qu'elle a atterri dans Module1.

Questions fréquentes

Où placer le code Workbook_Open dans Excel ?

Dans l'objet ThisWorkbook, pas dans un module standard. Ouvrez l'éditeur VBA (Alt+F11), repérez ThisWorkbook sous « Microsoft Excel Objets » dans votre projet, double-cliquez dessus et placez-y Private Sub Workbook_Open(). Un Sub Workbook_Open placé dans Module1 est identique en apparence mais ne se déclenche jamais, car Excel ne cherche l'événement que dans le module de code propre au classeur.

Pourquoi ma macro Workbook_Open ne s'exécute-t-elle pas ?

Presque toujours l'une de ces trois causes : le code est dans un Module au lieu de ThisWorkbook ; le fichier a été enregistré en .xlsx (ce qui supprime toutes les macros) au lieu de .xlsm ; ou l'utilisateur l'a ouvert avec les macros désactivées sans cliquer sur « Activer le contenu ». Vérifiez d'abord l'emplacement — c'est la cause la plus fréquente. Confirmez aussi qu'aucun code antérieur n'a laissé Application.EnableEvents = False.

Quelle est la différence entre Workbook_Open et Auto_Open ?

Workbook_Open est l'événement moderne, qui réside dans ThisWorkbook. Auto_Open est la macro héritée, qui réside dans un module standard. La différence pratique essentielle : Workbook_Open se déclenche quand le fichier est ouvert par une autre macro (Workbooks.Open), mais pas Auto_Open, sauf si vous appelez RunAutoMacros. Utilisez Workbook_Open ; ne conservez Auto_Open que pour maintenir de vieux fichiers.

Workbook_Open s'exécute-t-il quand une macro ouvre le fichier ?

Oui. Quand du code exécute Workbooks.Open "Report.xlsm", le Workbook_Open de ce classeur se déclenche normalement. Si vous devez précisément le supprimer — par exemple dans un traitement par lots automatisé — définissez Application.EnableEvents = False avant l'appel à Workbooks.Open, puis rétablissez-le à True ensuite.

Comment ouvrir un classeur sans exécuter Workbook_Open ?

Maintenez la touche Maj enfoncée pendant l'ouverture du fichier pour ignorer Workbook_Open le temps de cette ouverture. Depuis du code, définissez Application.EnableEvents = False avant Workbooks.Open et rétablissez-le à True ensuite. Les deux sont utiles quand une macro de démarrage se comporte mal et que vous devez entrer dans le fichier pour la corriger.

Testé dans

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

Guides associés : VBA Worksheet_Change · VBA Worksheet_SelectionChange · VBA On Error · VBA Workbook · Activer les macros dans Excel