VBA CurDir & ChDir dans Excel — pourquoi un chemin relatif atterrit dans le mauvais dossier

TL;DR — Un chemin relatif (un nom sans lecteur, comme "Reports") est résolu par rapport à CurDir, le répertoire de travail courant d'Excel — qui n'est pas le dossier de votre classeur et change chaque fois qu'une boîte de dialogue Ouvrir un fichier pointe vers un nouvel endroit. Ainsi MkDir "Reports" ou Open "data.csv" peut atterrir à un endroit différent à chaque exécution. Ancrez chaque chemin à ThisWorkbook.Path.

Sub WhereDoesThisGo()
    MkDir "Reports"                              ' cree sous CurDir - souvent PAS a cote du classeur
    MkDir ThisWorkbook.Path & "\Reports"         ' cree a cote de CE classeur, a chaque fois
End Sub

C'est le bug derrière toute une famille de rapports confus : « ma macro a créé le dossier au mauvais endroit », « elle a enregistré le fichier dans Documents », « ça marchait hier et aujourd'hui non ». Aucun n'est aléatoire. Ils remontent tous à un fait que personne ne songe à mettre en question — qu'un chemin relatif en VBA est résolu par rapport à un répertoire de travail qu'Excel gère pour vous, et que ce répertoire n'est pas là où vous le supposez. Comprenez CurDir, et chacun de ces bugs devient évitable avec une seule habitude.

Ce que vous allez apprendre

Le modèle mental — un chemin relatif ne signifie rien tant qu'il n'est pas résolu par rapport à CurDir
Pourquoi CurDir n'est pas ThisWorkbook.Path, et où il pointe réellement
Comment une boîte de dialogue Ouvrir un fichier change CurDir en silence au milieu d'une macro
Pourquoi ChDir ne peut pas changer de lecteur, et pourquoi ChDrive est une instruction distincte
Pourquoi ThisWorkbook.Path est vide pour un classeur qui n'a jamais été enregistré
L'unique habitude qui élimine toute la catégorie des bugs de mauvais dossier

Le modèle mental : un chemin relatif est résolu par rapport à CurDir

L'idée clé, c'est que VBA a deux sortes de chemin, et elles se comportent tout à fait différemment :

Absolu — commence par un lecteur ou une racine : "C:\Reports\March.xlsx". Il désigne exactement un endroit.
Relatif — sans lecteur, sans \ initial : "Reports" ou "data\in.csv". Il signifie « par rapport au répertoire courant », et VBA complète le reste à partir de CurDir.

CurDir est une fonction qui renvoie ce répertoire de travail — CurDir pour le lecteur courant, ou CurDir("D") pour un lecteur précis. Toute instruction qui prend un chemin — MkDir, RmDir, Open, Kill, Name, Dir — résout un chemin relatif par rapport à CurDir. Ainsi la question « où est passé mon dossier ? » est en réalité « que valait CurDir au moment où l'instruction s'est exécutée ? » — et c'est une question bien moins évidente qu'il n'y paraît.

CurDir n'est pas ThisWorkbook.Path

Voici l'idée fausse à la racine de tout : les gens supposent que le « répertoire courant » est le dossier où vit le classeur. Ce n'est pas le cas. Ce sont deux valeurs sans rapport :

Debug.Print CurDir              ' le repertoire de travail d'Excel - souvent C:\Users\You\Documents
Debug.Print ThisWorkbook.Path   ' ou CE classeur est enregistre - ex. D:\Projects\2026

CurDir démarre avec ce que Windows a remis à Excel au lancement (souvent votre dossier Documents) et n'a aucun lien avec l'endroit d'où vous avez ouvert votre classeur. Ainsi MkDir "Reports" ne crée pas un dossier à côté de votre fichier — il en crée un sous CurDir, qui peut être n'importe où. ThisWorkbook.Path, en revanche, pointe toujours vers le dossier contenant le classeur qui exécute le code. Chaque fois que vous voulez dire « à côté de mon classeur », c'est la propriété qu'il vous faut — jamais CurDir.

Une boîte de dialogue Ouvrir un fichier change CurDir en silence

La raison pour laquelle les bugs de mauvais dossier sont intermittents — bien hier, cassés aujourd'hui — c'est que CurDir ne tient pas en place. Windows le met à jour chaque fois que l'utilisateur (ou votre propre code) parcourt un dossier dans une boîte de dialogue de fichier :

Dim f As Variant
f = Application.GetOpenFilename          ' l'utilisateur va dans D:\Client\Inbox et choisit un fichier
' CurDir vaut desormais D:\Client\Inbox - il a bouge, de facon invisible
MkDir "Reports"                          ' cree D:\Client\Inbox\Reports, pas la ou vous vouliez

Rien dans votre code n'a dit « change de répertoire », et pourtant CurDir a bougé parce que la boîte de dialogue l'a défini. Tout chemin relatif après ce point se résout par rapport au nouvel emplacement. Voilà pourquoi la même macro écrit dans un dossier différent selon ce que l'utilisateur a cliqué cinq minutes plus tôt — une dépendance vraiment invisible, et un ticket de support insoluble à moins de savoir que CurDir est la pièce mobile.

ChDir change le dossier — mais pas le lecteur

Si vous voulez effectivement définir le répertoire de travail délibérément, ChDir est l'instruction — mais elle a un piège qui attrape presque tout le monde : ChDir change le dossier courant, pas le lecteur courant.

ChDir "D:\Data"     ' definit le dossier par defaut de D: sur \Data - mais vous etes ENCORE sur C:
CurDir              ' renvoie toujours C:\... - le lecteur n'a jamais change

Pour réellement passer à un autre lecteur, il vous faut ChDrive d'abord, et c'est une instruction distincte :

ChDrive "D"         ' bascule le lecteur courant sur D:
ChDir "D:\Data"     ' definit maintenant le dossier sur D:

Cette séparation — une instruction pour le lecteur, une autre pour le dossier — est un vestige de DOS, où chaque lecteur se souvenait de son propre répertoire courant. C'est exactement le genre de surprise qui rend fragile le « il suffit de définir le répertoire de travail ». Ce qui désigne le vrai correctif : ne gérez pas du tout de répertoire de travail.

L'habitude qui élimine toute la catégorie de bugs

Chaque bug de mauvais dossier ci-dessus disparaît si vous n'utilisez jamais de chemin relatif. Construisez un chemin absolu à partir de ThisWorkbook.Path et remettez celui-là à chaque instruction de fichier :

Dim base As String
base = ThisWorkbook.Path & Application.PathSeparator     ' ex. "D:\Projects\2026\"
MkDir base & "Reports"                                    ' toujours a cote du classeur
Open base & "data.csv" For Output As #1                   ' meme ancrage, aucune dependance a CurDir

Deux détails rendent cela robuste. Utilisez Application.PathSeparator plutôt qu'un "\" codé en dur pour que le code ne présume pas d'un séparateur, et faites attention au séparateur final pour ne jamais produire ...2026Reports par accident. Avec chaque chemin ancré à ThisWorkbook.Path, CurDir devient sans importance — il peut vagabonder là où les boîtes de dialogue le poussent et vos dossiers atterrissent tout de même exactement là où vous vouliez.

Un cas limite à protéger : ThisWorkbook.Path est une chaîne vide pour un classeur qui n'a jamais été enregistré. Si une macro peut s'exécuter avant son premier enregistrement, vérifiez If ThisWorkbook.Path = "" Then et demandez un emplacement plutôt que de construire un chemin cassé à partir de rien.

Le verdict honnête : ancrez à ThisWorkbook.Path, jamais à CurDir

CurDir vaut la peine d'être compris précisément pour que vous puissiez cesser d'en dépendre. Quatre règles :

Un chemin relatif suit CurDir → et CurDir est le répertoire de travail vagabond d'Excel, pas le dossier de votre classeur.
Une boîte de dialogue Ouvrir un fichier déplace CurDir → donc les chemins relatifs sont par intermittence erronés ; ne comptez jamais sur le répertoire de travail pour être là où vous l'avez laissé.
ChDir ne change pas de lecteur → il vous faut ChDrive d'abord ; les deux sont le signe que vous gérez un état que vous ne devriez pas avoir à gérer.
Ancrez à ThisWorkbook.Path → construisez des chemins absolus avec Application.PathSeparator, protégez le cas du classeur non enregistré, et le bug de mauvais dossier disparaît pour de bon.

C'est le fil qui relie les outils de dossier entre eux : MkDir et RmDir ne sont fiables qu'à hauteur du chemin que vous leur remettez, et un chemin relatif confie votre sort à CurDir. Donnez-leur un chemin absolu construit à partir de ThisWorkbook.Path, et les deux instructions font exactement ce que vous attendez, à chaque exécution.

Comment ExcelMaster aide

Réussir un chemin, c'est savoir que CurDir n'est pas le dossier de votre classeur, qu'une boîte de dialogue Ouvrir un fichier le déplace sans prévenir, que ChDir ne peut pas changer de lecteur, et que ThisWorkbook.Path est vide jusqu'à ce que le classeur soit enregistré — quatre pièges derrière chaque rapport « il a créé le dossier au mauvais endroit ».

ExcelMaster écrit des chemins qui atterrissent là où vous voulez dire. Décrivez la tâche — « enregistre l'export à côté de ce classeur », ou « construis le dossier de sortie dans le répertoire du projet » — et il produit un chemin absolu ancré à ThisWorkbook.Path avec Application.PathSeparator, jamais un chemin relatif qui dépend de CurDir, et il protège le cas non enregistré. Vous décrivez où le fichier doit aller ; il écrit le chemin qui l'y place à chaque exécution.

Questions fréquentes

Que renvoie CurDir en VBA ?

CurDir renvoie le répertoire de travail courant d'Excel — le dossier par rapport auquel les chemins relatifs sont résolus. CurDir donne le répertoire sur le lecteur courant ; CurDir("D") le donne pour le lecteur D. C'est généralement ce que Windows a défini au lancement d'Excel (souvent votre dossier Documents) et cela n'a aucun lien avec l'endroit où votre classeur est enregistré, alors ne l'utilisez pas pour signifier « à côté de mon fichier ».

Pourquoi ma macro VBA crée-t-elle le dossier ou enregistre-t-elle le fichier au mauvais endroit ?

Parce que vous avez utilisé un chemin relatif, et VBA l'a résolu par rapport à CurDir au lieu du dossier de votre classeur. CurDir est le répertoire de travail d'Excel, et une boîte de dialogue Ouvrir un fichier le change en silence, si bien que le même chemin relatif atterrit dans des dossiers différents selon les exécutions. Construisez un chemin absolu à partir de ThisWorkbook.Path — ThisWorkbook.Path & "\" & "Reports" — et l'emplacement cesse de dépendre de CurDir.

Quelle est la différence entre CurDir et ThisWorkbook.Path ?

CurDir est le répertoire de travail vagabond d'Excel — là où les chemins relatifs se résolvent, modifiable par n'importe quelle boîte de dialogue de fichier. ThisWorkbook.Path est le dossier où le classeur qui exécute le code est enregistré, et il ne bouge pas. Quand vous voulez dire « à côté de ce classeur », utilisez toujours ThisWorkbook.Path ; n'utilisez CurDir que lorsque vous voulez vraiment le répertoire de travail, ce qui est rare.

Pourquoi ChDir ne change-t-il pas de lecteur en VBA ?

Parce que ChDir ne change que le dossier courant, pas le lecteur courant — un vestige de DOS, où chaque lecteur gardait son propre répertoire courant. ChDir "D:\Data" alors que vous êtes sur C: définit le dossier par défaut de D: mais vous laisse sur C:. Pour changer de lecteur, appelez ChDrive "D" d'abord, puis ChDir "D:\Data". En pratique, il est plus simple d'éviter entièrement le répertoire de travail et d'utiliser des chemins absolus.

Pourquoi ThisWorkbook.Path est-il vide ?

ThisWorkbook.Path renvoie une chaîne vide quand le classeur n'a jamais été enregistré — un classeur non enregistré n'a pas encore de dossier. Si une macro peut s'exécuter avant le premier enregistrement, vérifiez If ThisWorkbook.Path = "" Then et demandez un emplacement à l'utilisateur (avec Application.GetSaveAsFilename) au lieu de construire un chemin à partir d'une chaîne vide, ce qui produirait un chemin relatif résolu par rapport à CurDir.

Testé dans

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

Guides associés : VBA MkDir · VBA RmDir · VBA Dir · VBA Open Workbook · VBA Check If File Exists