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

VBA Environ dans Excel — lire les chemins Windows sans coder en dur un dossier utilisateur

|

VBA Environ dans Excel — lire les chemins Windows sans coder en dur un dossier utilisateur

TL;DR — Environ("USERPROFILE"), Environ("TEMP"), Environ("USERNAME") lisent les variables que Windows donne à chaque programme, si bien que vous ne codez jamais en dur C:\Users\John\... — un chemin qui casse sur toutes les autres machines. Le piège est silencieux : un nom absent ou mal orthographié renvoie une chaîne vide, pas une erreur, si bien que Environ("TMEP") & "\out.txt" devient "\out.txt" et atterrit à la racine du disque. Traitez chaque résultat d'Environ comme possiblement vide.

Sub EnvironDemo()
    Debug.Print Environ("USERPROFILE")   ' C:\Users\Ann
    Debug.Print Environ("TEMP")          ' C:\Users\Ann\AppData\Local\Temp
    Debug.Print Environ("USERNAME")      ' Ann
    Debug.Print Environ("TMEP")          ' "" - mal orthographie, pas d'erreur, juste vide
End Sub

Chaque programme Windows reçoit une petite table de chaînes NAME=VALUE — le bloc d'environnement — qui enregistre où vit le profil de l'utilisateur, où vont les fichiers temporaires, qui est connecté, et davantage. Environ est la fenêtre de VBA sur cette table. C'est la façon correcte et portable de trouver les dossiers propres à la machine, et il a exactement une habitude que vous devez respecter : quand vous demandez un nom qu'il n'a pas, il répond par du vide plutôt que de se plaindre.

Ce que vous allez apprendre

  • Le modèle mental — Environ lit la table vivante NAME=VALUE de Windows pour ce programme
  • Tout l'intérêt : des chemins portables au lieu de C:\Users\<nom>\... codés en dur
  • Pourquoi une variable absente ou mal orthographiée renvoie "" — le bug silencieux — et comment s'en prémunir
  • Les deux formes d'appel : Environ("NAME") par nom et Environ(n) par indice numérique
  • Pourquoi le bloc est un instantané pris au démarrage d'Excel, et ce que « périmé » veut dire ici
  • Ce qu'Environ ne sait pas faire — écrire des variables, ou lire une variable modifiée après le lancement

Le modèle mental : Environ lit la table nom=valeur de Windows

Quand Windows démarre un programme, il copie un ensemble de paires NAME=VALUE dans la mémoire de ce programme — l'environnement de processus. Il contient des entrées comme USERPROFILE=C:\Users\Ann, TEMP=C:\Users\Ann\AppData\Local\Temp, COMPUTERNAME=DESK-01, et des dizaines d'autres. Environ se contente de chercher un nom dans cette table et d'en renvoyer la valeur sous forme de texte :

Dim tempDir As String
tempDir = Environ("TEMP")     ' demande a la table la valeur stockee sous "TEMP"

C'est tout le modèle. Environ est une lecture d'une table de correspondance que Windows a remplie avant qu'Excel ne s'ouvre. Ce n'est pas une interrogation en direct des paramètres Windows, ni le registre, ni le répertoire de travail courant — ce sont des choses différentes. Une fois que vous le voyez comme « chercher un nom dans une table », les règles ci-dessous suivent.

Remplacer les chemins utilisateur codés en dur — tout l'intérêt

La raison même d'utiliser Environ : cesser d'écrire des chemins qui ne marchent que sur votre machine. Cette ligne est un grand classique de macro qui casse dès que quelqu'un d'autre l'exécute :

Open "C:\Users\John\AppData\Roaming\MyApp\log.txt" For Append As #1   ' ne marche que pour John

Il n'y a aucun utilisateur nommé John sur le PC de quiconque. Reconstruisez le chemin à partir de l'environnement et il marche partout :

Dim p As String
p = Environ("APPDATA") & "\MyApp\log.txt"      ' C:\Users\<utilisateur>\AppData\Roaming\MyApp\log.txt
Open p For Append As #1

Les variables que vous emploierez le plus : USERPROFILE (le dossier personnel de l'utilisateur), APPDATA et LOCALAPPDATA (données applicatives par utilisateur), TEMP (fichiers temporaires), USERNAME (qui est connecté), COMPUTERNAME et PUBLIC. Passez le résultat à Open, Dir ou une commande Shell et votre macro voyage vers n'importe quelle machine sans retouche.

Une variable absente renvoie du vide, pas une erreur

Voici le piège qui produit les échecs les plus déroutants, et c'est une conséquence directe du fait qu'Environ est une recherche dans une table : demandez un nom qui n'y est pas, et vous obtenez une chaîne vide — pas d'erreur, pas d'avertissement. Une faute de frappe d'un seul caractère suffit :

Dim p As String
p = Environ("TMEP") & "\out.txt"   ' TMEP n'existe pas -> "" & "\out.txt" = "\out.txt"
Open p For Output As #1            ' cree C:\out.txt a la racine du disque - pas ce que vous vouliez

Rien ne se plaint à la ligne Environ, parce que « introuvable » est une réponse légitime pour elle. Les dégâts apparaissent plus tard et ailleurs — un fichier à la racine du disque, un chemin qui ne s'ouvre pas, un dossier créé au mauvais endroit — loin de la faute de frappe qui les a causés. Protégez celles qui comptent :

Dim tempDir As String
tempDir = Environ("TEMP")
If tempDir = "" Then
    MsgBox "TEMP is not set - cannot continue.": Exit Sub
End If

La règle à emporter : un résultat vide d'Environ est normal, pas exceptionnel — vérifiez-le chaque fois qu'une valeur manquante enverrait un fichier au mauvais endroit. C'est l'écho, côté bloc d'environnement, de ce même échec silencieux qui rend tant d'appels hors d'Excel dangereux : la réponse à une erreur est un vide discret, pas un arrêt bruyant.

Deux formes d'appel : par nom et par indice

Environ a deux visages, et ils renvoient des choses différentes. Passez une chaîne et vous obtenez la valeur de cette variable. Passez un nombre et vous obtenez la paire brute NAME=VALUE entière à cette position, ce qui vous permet d'énumérer tout le bloc :

Debug.Print Environ("PATH")     ' par nom  -> la valeur seule : C:\Windows;C:\Windows\System32;...

Dim i As Integer, entry As String
i = 1
Do
    entry = Environ(i)          ' par indice -> la paire brute : "USERPROFILE=C:\Users\Ann"
    If entry = "" Then Exit Do  ' la chaine vide marque la fin de la liste
    Debug.Print entry
    i = i + 1
Loop

La forme par indice est la façon de découvrir quelles variables existent sur une machine — utile pour le diagnostic. Notez le même signal de chaîne vide qui joue un double rôle : pour un nom il veut dire « introuvable », et pour un indice il veut dire « au-delà de la fin de la liste ». Boucles et recherches s'appuient toutes deux sur cette unique convention.

Le piège de l'instantané, et ce qu'Environ ne peut pas faire

Deux limites piègent ceux qui attendent d'Environ une vue en direct de Windows.

C'est un instantané pris au démarrage. Excel a copié le bloc d'environnement au moment de son lancement. Si vous changez une variable après coup — via les Propriétés système, une commande setx ou un autre outil — Environ, dans cette même session Excel, ne verra pas la nouvelle valeur. Il reflète le monde tel qu'il était à l'ouverture d'Excel ; c'est un redémarrage qui le rafraîchit.

Il ne fait que lire ; il ne peut pas écrire. Il n'existe pas de Environ("X") = "Y". Pour définir une variable, ou pour lire une variable modifiée après le démarrage, il vous faut la collection Environment de l'objet WScript.Shell via CreateObject :

Dim sh As Object
Set sh = CreateObject("WScript.Shell")
Debug.Print sh.Environment("Process")("TEMP")   ' la valeur du processus en direct
' sh.Environment("User")("MYVAR") = "hello"      ' cette forme PEUT ecrire une variable utilisateur

Environ ne peut pas non plus vous dire de quelle portée une valeur provient — utilisateur, système ou processus. Windows les fusionne dans le bloc unique que vous voyez, et Environ ne signale que le résultat fusionné. Pour les chemins portables du quotidien, c'est exactement suffisant ; ne recourez à WScript.Shell.Environment que lorsque vous devez écrire une variable ou en lire une fraîchement modifiée.

Le verdict honnête : l'outil des chemins portables, traité comme possiblement vide

Environ mérite sa place pour un seul travail et le fait bien : transformer des dossiers propres à la machine en chemins qui voyagent. Les erreurs remontent toutes à un oubli — une recherche peut échouer en silence. Quatre règles en font le tour :

  • Servez-vous-en pour des chemins portables → Environ("APPDATA") & "\MyApp\...", jamais un C:\Users\<nom>\... codé en dur.
  • Traitez chaque résultat comme possiblement vide → un nom absent ou mal orthographié renvoie "", pas une erreur. Protégez les valeurs dont l'absence enverrait un fichier au mauvais endroit.
  • Connaissez les deux formes → Environ("NAME") renvoie la valeur ; Environ(n) renvoie la paire brute NAME=VALUE et vous laisse énumérer le bloc.
  • C'est un instantané de démarrage, et en lecture seule → il ne verra pas une variable modifiée après le lancement d'Excel, et il ne peut pas en définir une. Pour cela, utilisez WScript.Shell.Environment.

Réussissez ces points et toute une famille de bugs de chemin « ça marche sur mon PC, ça casse sur le leur » disparaît — vous cessez de nommer un utilisateur précis et commencez à demander à la machine où se trouvent réellement ses dossiers.

Comment ExcelMaster aide

Les bugs d'Environ qui font perdre du temps sont ceux du chemin silencieux : une macro codée en dur sur C:\Users\John qui échoue pour tous les autres, un nom de variable mal tapé qui dépose un fichier à la racine du disque sans erreur, un chemin bâti sur TEMP en supposant que la variable était définie. Chacun vient soit de ne pas utiliser l'environnement, soit de lui faire confiance sans vérifier.

ExcelMaster écrit correctement la logique des chemins portables. Décrivez la destination — « enregistre un journal dans le dossier AppData de l'utilisateur », ou « écris des fichiers temporaires dans son dossier Temp » — et il bâtit le chemin à partir de la bonne variable Environ, vérifie que la valeur est revenue non vide, et alors seulement ouvre ou crée le fichier. Vous décrivez quel dossier, pas quel utilisateur, et il produit du code qui tourne sans changement sur chaque machine.

Questions fréquentes

Comment obtenir le nom d'utilisateur Windows courant en VBA ?

Utilisez Environ("USERNAME") — il renvoie le nom de connexion de l'utilisateur courant, par exemple Ann. C'est la façon légère d'identifier qui exécute la macro sans appel à une API Windows. Si vous avez besoin du nom d'affichage complet ou du domaine plutôt que du nom de connexion, cela demande une API comme GetUserNameEx, mais pour tamponner un journal ou construire un chemin par utilisateur, Environ("USERNAME") est la réponse standard.

Comment obtenir le chemin du dossier Temp ou AppData de l'utilisateur en VBA ?

Environ("TEMP") renvoie le dossier temporaire propre à l'utilisateur (typiquement C:\Users\<nom>\AppData\Local\Temp), et Environ("APPDATA") renvoie le dossier de données applicatives itinérantes. Les deux sont propres à l'utilisateur, donc construire des chemins à partir d'eux évite de coder en dur C:\Users\<nom>. Vérifiez toujours que le résultat n'est pas vide avant de l'utiliser : t = Environ("TEMP") : If t = "" Then Exit Sub, puisqu'une variable absente renvoie une chaîne vide au lieu de lever une erreur.

Pourquoi Environ renvoie-t-il une chaîne vide en VBA ?

Parce que le nom de variable que vous avez demandé n'est pas présent dans l'environnement de processus — le plus souvent une faute de frappe (TMEP au lieu de TEMP), une variable qui n'existe que dans une autre portée, ou une variable créée après le démarrage d'Excel. Environ traite « introuvable » comme une réponse normale et renvoie "" sans erreur. Ajoutez une protection : If Environ("NAME") = "" Then .... Si la variable a été définie après le lancement d'Excel, redémarrez Excel ou lisez-la en direct via CreateObject("WScript.Shell").Environment("Process")("NAME").

VBA Environ peut-il définir ou modifier une variable d'environnement ?

Non. Environ est en lecture seule — il n'existe pas de forme d'affectation. Pour créer ou modifier une variable, utilisez l'objet WScript.Shell : CreateObject("WScript.Shell").Environment("User")("MYVAR") = "value" définit une variable utilisateur persistante. Notez que tout changement que vous faites n'apparaîtra pas dans Environ pour la session Excel courante, car Environ lit un instantané pris au lancement d'Excel ; un redémarrage est nécessaire pour qu'il voie les nouvelles valeurs.

Comment lister toutes les variables d'environnement en VBA ?

Appelez Environ avec un nombre au lieu d'un nom — Environ(1), Environ(2), et ainsi de suite — et chacun renvoie la paire brute NAME=VALUE à cette position. Bouclez jusqu'à ce qu'il renvoie une chaîne vide, qui marque la fin de la liste : i = 1 : Do : e = Environ(i) : If e = "" Then Exit Do : Debug.Print e : i = i + 1 : Loop. Cela énumère tout le bloc d'environnement, ce qui est pratique pour le diagnostic quand un chemin ne se résout pas comme prévu.

Testé dans

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

Guides connexes : VBA Shell · VBA CreateObject & GetObject · VBA FreeFile & Open · VBA Dir · VBA CurDir & ChDir