Sortir les secrets du dépôt : variables d’environnement pour WordPress

Un développeur junior, pressé par un délai serré, commit un jour son wp-config.php complet dans le dépôt Git du projet, identifiants de base de données inclus, pour dépanner un collègue à distance. Le fichier est retiré du dépôt dès le lendemain matin. Le mot de passe, lui, reste consultable indéfiniment dans l’historique des commits, à moins de réécrire cet historique — une opération lourde et risquée sur un dépôt déjà partagé par toute une équipe.

Cet incident, banal et pourtant fréquent, illustre pourquoi les secrets (mots de passe de base de données, clés d’API, jetons de service tiers) ne devraient jamais résider dans un fichier versionné avec le reste du code. Les variables d’environnement offrent une séparation nette entre le code, qui peut être partagé et versionné sans risque, et la configuration sensible, qui reste propre à chaque environnement.

Le principe : séparer code et configuration

Un fichier .env, placé à la racine du projet mais explicitement exclu du versionnement via .gitignore, contient les valeurs sensibles propres à l’environnement local, de préproduction ou de production :

# .env — jamais commité, jamais partagé tel quel
DB_NAME=exemple_prod
DB_USER=exemple_prod_user
DB_PASSWORD=une-valeur-longue-et-aleatoire
DB_HOST=localhost

Le fichier .gitignore du projet doit explicitement l’exclure :

# .gitignore
.env
.env.local

Charger les variables dans wp-config.php

Sans dépendance supplémentaire, une fonction simple lit et injecte les variables du fichier .env dans l’environnement PHP avant que wp-config.php ne les utilise :

function charger_env( $chemin ) {
    if ( ! file_exists( $chemin ) ) {
        return;
    }
    foreach ( file( $chemin, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES ) as $ligne ) {
        if ( str_starts_with( trim( $ligne ), '#' ) ) {
            continue;
        }
        [ $cle, $valeur ] = array_pad( explode( '=', $ligne, 2 ), 2, '' );
        putenv( trim( $cle ) . '=' . trim( $valeur ) );
    }
}

charger_env( __DIR__ . '/.env' );

define( 'DB_NAME', getenv( 'DB_NAME' ) );
define( 'DB_USER', getenv( 'DB_USER' ) );
define( 'DB_PASSWORD', getenv( 'DB_PASSWORD' ) );
define( 'DB_HOST', getenv( 'DB_HOST' ) );

Pour des besoins plus complets (typage des valeurs, valeurs par défaut, imbrication), des bibliothèques comme vlucas/phpdotenv, installables via Composer, offrent une implémentation plus robuste que ce script minimal, tout en suivant exactement le même principe.

Un fichier .env.example versionné, lui, sans valeurs réelles

Pour que l’équipe sache quelles variables sont attendues sans exposer aucune valeur réelle, un fichier .env.example versionné documente la structure attendue :

# .env.example — celui-ci EST versionné
DB_NAME=
DB_USER=
DB_PASSWORD=
DB_HOST=
MAILGUN_API_KEY=

Chaque nouveau membre de l’équipe copie ce fichier en .env local et le complète avec ses propres valeurs, sans jamais avoir à demander « quelles variables faut-il définir ? ».

Que faire si un secret a déjà été commité

La rotation reste la seule réponse fiable, la suppression de l’historique Git n’étant qu’une mesure complémentaire, pas suffisante à elle seule (une copie locale du dépôt peut déjà exister ailleurs) :

1. Changer immédiatement le mot de passe ou régénérer la clé exposée sur le service concerné, sans attendre.
2. Mettre à jour le fichier .env de chaque environnement avec la nouvelle valeur.
3. Envisager, seulement ensuite, une réécriture de l’historique Git avec un outil comme git filter-repo si la sensibilité de la donnée le justifie, en coordination avec toute l’équipe.

Ce que cette approche ne couvre pas seule

Sortir un secret du dépôt Git ne suffit pas s’il reste ensuite affiché en clair dans les journaux d’erreur ou transmis sans chiffrement entre deux services.

La gestion des variables d’environnement protège la chaîne de versionnement du code, pas l’ensemble du cycle de vie du secret : un mot de passe de base de données qui apparaît dans un message d’erreur PHP journalisé, ou une clé d’API transmise en clair sur une connexion non chiffrée entre deux serveurs, restent des risques distincts à traiter séparément.

En résumé

Séparer les secrets du code versionné via un fichier .env exclu du dépôt, associé à un .env.example documentant la structure attendue, évite l’un des incidents les plus fréquents et les plus difficiles à corriger a posteriori : un mot de passe qui reste consultable indéfiniment dans l’historique d’un dépôt Git partagé.