# direnv pour charger le bon environnement en changeant de dossier de projet

> Un fichier .envrc évite d'oublier de sourcer manuellement les bonnes variables en changeant de dossier de projet. Installation, configuration et automatisation pas à pas.

- Auteur : Clément Hadrot
- Publié le : 2023-07-26
- Mis à jour le : 2023-07-26
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/direnv-charger-environnement-projet/

## L’essentiel

- direnv charge et décharge automatiquement les variables selon le dossier courant
- Un fichier .envrc par projet, jamais partagé avec les identifiants réels
- L'autorisation explicite via direnv allow protège d'une exécution non désirée

`source .env.recette` puis, deux heures plus tard sur un autre projet dans un autre terminal, l'oubli du même geste avant de lancer une commande WP-CLI qui s'exécute alors avec les mauvais identifiants de base de données : ce scénario, répété plusieurs fois par semaine sur un poste de développement gérant une dizaine de projets simultanément, a justifié l'installation de direnv.

direnv est un utilitaire qui s'intègre au shell et surveille le dossier courant à chaque changement de répertoire. Si un fichier `.envrc` existe dans le dossier, ses variables sont chargées automatiquement ; en quittant ce dossier, elles sont déchargées tout aussi automatiquement. Le geste manuel de sourcer un fichier de variables, source classique d'oubli, disparaît purement et simplement.

## Installer et activer direnv

L'installation varie selon le système, mais reste simple : un gestionnaire de paquets système ou `brew install direnv` sur macOS suffisent. L'étape qui suit compte davantage : direnv doit être accroché au shell utilisé (Bash, Zsh, Fish), via une ligne ajoutée à son fichier de configuration :

```
# Dans ~/.bashrc ou ~/.zshrc
eval "$(direnv hook bash)"
```

Après rechargement du shell, direnv surveille chaque changement de dossier et recherche la présence d'un fichier `.envrc`.

## Écrire un fichier .envrc de projet

Un fichier `.envrc` placé à la racine d'un projet WordPress peut définir les variables nécessaires aux commandes WP-CLI et aux scripts du projet :

```
export WP_ENV=recette
export DB_NAME=projet_recette
export DB_USER=projet_recette
export DB_HOST=127.0.0.1
export PATH_TO_WORDPRESS=/var/www/projet/recette

PATH_add bin
```

La fonction `PATH_add`, fournie par direnv, ajoute un dossier au `PATH` uniquement pour la durée où l'on se trouve dans ce projet, ce qui permet par exemple d'exposer des scripts internes au projet sans les installer globalement sur la machine.

> L'essentiel à retenir : direnv charge et décharge automatiquement les variables selon le dossier courant ; Un fichier .envrc par projet, jamais partagé avec les identifiants réels ; L'autorisation explicite via direnv allow protège d'une exécution non désirée

## L'étape d'autorisation, une protection volontaire

Par sécurité, direnv n'exécute jamais un fichier `.envrc` automatiquement à sa première rencontre, ni après une modification de son contenu. Une autorisation explicite est requise :

```
direnv allow .
```

Cette étape empêche qu'un fichier `.envrc` malveillant, récupéré par exemple en clonant un dépôt Git douteux, ne s'exécute silencieusement dès l'ouverture d'un terminal dans ce dossier. Toute modification ultérieure du fichier redemande la même autorisation, ce qui garantit qu'aucun changement de contenu ne passe inaperçu.

## Ce qu'il ne faut jamais mettre dans un .envrc versionné

Un fichier `.envrc` versionné dans le dépôt Git du projet ne doit contenir aucun identifiant réel de production. La pratique retenue consacre le fichier `.envrc` versionné aux valeurs de développement local, non sensibles, et charge les valeurs sensibles depuis un fichier séparé explicitement exclu du dépôt :

- `.envrc` : versionné, valeurs de développement local uniquement
- `.envrc.local` : ignoré par Git, chargé depuis `.envrc` via `source_env_if_exists .envrc.local`

Cette séparation permet à toute l'équipe de bénéficier d'une configuration de base fonctionnelle immédiatement après avoir cloné le dépôt, tout en gardant les valeurs propres à chaque poste de travail hors du contrôle de version.

## Un usage quotidien qui devient invisible

Après quelques semaines d'usage, le geste de sourcer manuellement un fichier de variables devient un souvenir plutôt qu'une habitude. Ouvrir un terminal, se déplacer dans le dossier d'un projet, et voir l'invite de commande confirmer que les bonnes variables sont chargées — ce cycle remplace entièrement l'ancienne méthode, sans qu'aucune commande supplémentaire ne soit jamais tapée à la main.

## Ce que direnv ne gère pas

direnv charge des variables d'environnement locales à un poste de travail ; il ne synchronise rien entre les membres d'une équipe et ne remplace pas un coffre-fort de secrets pour les valeurs de production. La question de la gestion centralisée des secrets, pour des environnements partagés ou pour la production, relève d'un outillage distinct et plus rigoureux que de simples fichiers locaux.

## En résumé

direnv règle un problème précis et récurrent — l'oubli de charger le bon contexte en changeant de projet — avec un coût d'installation minimal et une protection intégrée contre l'exécution non désirée. Sur un poste qui jongle entre plusieurs projets dans la même journée, ce petit changement d'habitude élimine une classe entière d'erreurs bêtes qui n'ont, autrement, aucune raison de disparaître d'elles-mêmes.