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 binLa 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’é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.envrcviasource_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.
