Un email de confirmation de commande parti depuis un environnement de recette vers l’adresse d’un vrai client, parce que la base de données de test contenait encore ses coordonnées réelles copiées depuis la production : c’est l’incident classique qui pousse à s’intéresser sérieusement à la distinction entre environnements. Depuis WordPress 5.5, une fonction native, wp_get_environment_type(), permet justement d’éviter ce genre de scénario sans dépendre d’une extension.
Cet article se concentre sur la définition de la constante WP_ENVIRONMENT_TYPE, son usage pour désactiver certains comportements hors production, et un indicateur visuel simple ; la mise en place de l’environnement de recette lui-même (hébergement, synchronisation de base de données) est un sujet à part entière.
Définir la constante dans wp-config.php
La constante WP_ENVIRONMENT_TYPE se déclare dans wp-config.php, avant la ligne qui charge le reste du cœur WordPress. Quatre valeurs sont reconnues nativement par le cœur : local, development, staging et production (valeur par défaut si la constante est absente).
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Sur un parc de plusieurs environnements, la meilleure pratique consiste à ne pas coder cette valeur en dur dans un fichier versionné, mais à la définir via une variable d’environnement système, lue ensuite dans wp-config.php :
define( 'WP_ENVIRONMENT_TYPE', getenv( 'WP_ENV' ) ?: 'production' );Lire la valeur avec wp_get_environment_type
Une fois la constante définie, la fonction wp_get_environment_type() la restitue n’importe où dans le code, avec la même valeur normalisée quelle que soit la casse utilisée à la déclaration.
if ( 'production' !== wp_get_environment_type() ) {
// Comportement réservé aux environnements non-production
}Désactiver l’envoi d’emails hors production
L’usage le plus immédiat consiste à couper l’envoi réel des emails transactionnels hors production, remplacé par une simple journalisation, ce qui aurait évité l’incident cité en introduction.
function projet_bloquer_emails_hors_prod( $args ) {
if ( 'production' !== wp_get_environment_type() ) {
error_log( 'Email intercepté (hors production) : ' . $args['to'] );
return array();
}
return $args;
}
add_filter( 'wp_mail', 'projet_bloquer_emails_hors_prod' );Retourner un tableau vide depuis le filtre wp_mail empêche l’envoi effectif tout en laissant une trace exploitable dans les journaux, pratique pour vérifier que l’email aurait bien été déclenché sans polluer une vraie boîte de réception.
Empêcher l’indexation des moteurs de recherche
Un environnement de recette accessible publiquement finit toujours, tôt ou tard, par être indexé si rien n’en empêche l’exploration. Forcer le réglage « Décourager les moteurs de recherche d’indexer ce site » via code, conditionné à l’environnement, sécurise ce point même si quelqu’un décoche accidentellement la case dans les réglages.
function projet_forcer_noindex_hors_prod() {
if ( 'production' !== wp_get_environment_type() ) {
update_option( 'blog_public', 0 );
}
}
add_action( 'init', 'projet_forcer_noindex_hors_prod' );Afficher un indicateur visuel dans l’administration
Le risque de confusion humaine reste réel : un utilisateur qui travaille sur plusieurs environnements ouverts dans des onglets différents peut modifier du contenu sur le mauvais site sans s’en rendre compte. Un bandeau coloré dans la barre d’administration, affiché uniquement hors production, réduit sensiblement ce risque.
function projet_indicateur_environnement( $wp_admin_bar ) {
$environnement = wp_get_environment_type();
if ( 'production' === $environnement ) {
return;
}
$wp_admin_bar->add_node( array(
'id' => 'indicateur-environnement',
'title' => 'Environnement : ' . strtoupper( $environnement ),
) );
}
add_action( 'admin_bar_menu', 'projet_indicateur_environnement', 999 );Ce que cette fonction ne fait pas
- Elle ne synchronise ni ne bascule automatiquement une base de données entre environnements.
- Elle ne remplace pas un fichier
wp-config.phpdistinct par environnement pour les identifiants de base de données. - Elle ne protège pas physiquement un environnement de recette contre un accès public : cela reste du ressort de l’hébergement (authentification HTTP, restriction d’IP).
Sur chaque nouveau projet, je définis
WP_ENVIRONMENT_TYPEdès la création du dépôt, avant même le premier commit de code métier : c’est l’un des rares réglages qu’il est plus coûteux d’ajouter après coup, une fois plusieurs comportements déjà câblés sans en tenir compte.
En résumé
wp_get_environment_type() et la constante WP_ENVIRONMENT_TYPE forment un mécanisme natif, disponible depuis WordPress 5.5, pour adapter le comportement du code selon l’environnement d’exécution. Emails coupés, indexation bloquée, indicateur visuel : trois usages simples qui, mis bout à bout, évitent la plupart des incidents liés à la confusion entre recette et production.
