Erreurs wp-config.php de WordPress : mésconfigurations courantes et correctifs

Ce que fait réellement wp-config.php (et pourquoi les erreurs font mal)

wp-config.php n’est pas juste « l’endroit où vit le mot de passe de la base de données ». C’est le panneau de contrôle du démarrage de WordPress : où il lit les données, ce qu’il suppose concernant le schéma/hôte de la requête, comment il journalise, quelle couche de cache il tente de charger et quels tokens de sécurité il considère fiables.

La plupart des fichiers de configuration sont lus tard, après l’initialisation du framework. WordPress lit wp-config.php tôt et souvent. Cela a deux conséquences opérationnelles :

• Les modes de défaillance sont immédiats. Erreurs de syntaxe, constantes incorrectes, chemins d’inclusion erronés : vous obtenez des écrans blancs, des 500, ou « Error establishing a database connection ».
• Le mauvais comportement peut être subtil. Le site « fonctionne », mais cron ne se déclenche pas, les cookies d’admin deviennent invalides, du contenu mixte apparaît, le cache d’objets thrash, ou vos logs se remplissent à un rythme qui impressionnerait un bot DDoS.

Principes pour éviter les ennuis

• Rendre les modifications réversibles. Si vous ne pouvez pas revenir en arrière en quelques secondes, vous ne « configurez » pas, vous jouez.
• Privilégier les secrets pilotés par l’environnement. Moins il y a d’identifiants codés en dur, moins ils risquent de finir dans un repo git, une sauvegarde ou un pastebin tragique.
• Ne pas traiter wp-config.php comme une poubelle. C’est tentant. Résistez. Si vous définissez dix constantes sans rapport pour « coller » le comportement d’un plugin, vous construisez un sanctuaire aux futures pannes.

Un petit signal d’alerte : quand une équipe dit « C’est juste un tweak de config », c’est généralement le moment où vous devriez planifier une fenêtre de maintenance.

Blague 1 : wp-config.php est comme une boîte « casser la vitre ». Si vous l’ouvrez à la légère, vous avez déjà une mauvaise journée.

Mode opératoire de diagnostic rapide

Voici le flux « arrêter l’hémorragie ». Il est biaisé pour la production : changements minimes, signal maximal. Faites-les dans l’ordre sauf si vous avez déjà une preuve flagrante.

Première étape : confirmer la classe de défaillance (parse PHP vs WordPress vs infra)

1. Vérifier le statut HTTP et le corps de la réponse. Un 500 avec un corps vide signifie souvent une erreur fatale/parse PHP ; « Error establishing a database connection » signifie que WordPress attrape des échecs de connexion DB.
2. Suivre les logs PHP-FPM / serveur web. Si vous voyez « Parse error » référant wp-config.php, arrêtez-vous et corrigez la syntaxe avant toute autre chose.
3. Valider que PHP peut lire le fichier. Des permissions incorrectes peuvent ressembler à un comportement « configuration manquante ».

Deuxième étape : valider la connectivité à la base depuis l’hôte applicatif

1. Résoudre l’hôte DB. La dérive DNS provoque de vraies pannes.
2. Se connecter avec les mêmes identifiants. Prouvez que le nom d’utilisateur/mot de passe et le chemin réseau sont valides.
3. Confirmer les attentes de jeu de caractères/collation. Des valeurs mal réglées ne bloquent pas toujours le démarrage, mais peuvent corrompre les données au fil du temps ou casser des migrations.

Troisième étape : évaluer les hypothèses sur le schéma/hôte de la requête

1. Derrière un reverse proxy ? Si les en-têtes $_SERVER ne sont pas approuvés correctement, vous obtenez des boucles de redirection, du contenu mixte ou des échecs de connexion admin.
2. Vérifier WP_HOME et WP_SITEURL. Un caractère de travers peut laisser votre admin bloqué derrière des redirections infinies.

Quatrième étape : rechercher les bascules « utiles » qui sont devenues des passifs

1. Drapeaux de debug. Avoir WP_DEBUG activé en production est un coût de performance et un risque de fuite de données.
2. Drop-ins de cache. Des mauvais réglages Redis/Memcached causent des comportements étranges de connexion et des pics CPU qui se font passer pour « WordPress lent ».
3. Paramètres cron. Désactiver WP-Cron sans un vrai cron système est la façon dont les newsletters cessent d’être envoyées et personne ne s’en aperçoit jusqu’à ce que le marketing râle.

Si vous ne retenez qu’une chose : prouvez les bases d’abord — syntaxe, permissions, atteignabilité DB — avant de débattre de la philosophie du cache.

Faits et historique utiles

• Fait 1 : Historiquement, WordPress utilisait wp-config-sample.php comme modèle ; des gens le copient encore à l’identique, y compris des hypothèses obsolètes sur les salts, le debug et les valeurs par défaut d’hôte DB.
• Fait 2 : Le réglage $table_prefix existe en partie parce que WordPress anticipait des bases partagées et des installations multiples dans un même schéma — courant à l’époque des hébergements à bas coût.
• Fait 3 : Les « drop-ins » WordPress (comme object-cache.php) sont chargés avant la plupart des plugins. Un drop-in cassé peut tout casser alors que votre liste de plugins semble innocente.
• Fait 4 : Le config supporte define('WP_CACHE', true) surtout pour se coordonner avec des plugins de cache, mais le définir sans le reste de la pile est une classique demi-installation.
• Fait 5 : DISABLE_WP_CRON était une réponse pragmatique à la planification dépendante du trafic. Sur les sites à faible trafic, WP-Cron est pratiquement « peut-être plus tard ».
• Fait 6 : Beaucoup d’hébergeurs exécutent PHP sous un utilisateur différent (pool FPM) de votre utilisateur SSH. Des permissions qui « ont l’air correctes » dans votre shell peuvent être illisibles pour PHP.
• Fait 7 : FORCE_SSL_ADMIN précède la norme moderne « tout derrière TLS ». Il peut encore importer quand vous avez une terminaison TLS partagée ou des couches proxy mixtes.
• Fait 8 : WordPress peut prendre des constantes DB depuis des variables d’environnement. Ce n’est pas juste du discours « 12-factor » à la mode ; c’est un moyen réel d’éviter de commettre des secrets dans des images ou des repos.
• Fait 9 : L’emplacement canonique de wp-config.php peut être un répertoire au-dessus du document root. C’est du durcissement à l’ancienne, et ça marche toujours.

La plupart de ces fonctionnalités sont nées des contraintes d’hébergement partagé puis ont été conservées en production sérieuse. C’est pourquoi wp-config.php peut donner l’impression d’un chantier archéologique.

Tâches pratiques : commandes, sorties et décisions

Ce sont des tâches « exécutez maintenant ». Chacune inclut : la commande, ce que signifie la sortie, et quelle décision prendre ensuite. Elles sont écrites pour un hôte Linux typique exécutant Nginx/Apache + PHP-FPM + MySQL/MariaDB, mais la logique s’applique ailleurs.

Tâche 1 : Vérifier que wp-config.php existe et n’est pas un lien symbolique mort

cr0x@server:~$ ls -la /var/www/html/wp-config.php
-rw-r----- 1 www-data www-data 3890 Dec 27 10:11 /var/www/html/wp-config.php

Ce que cela signifie : Le fichier existe, est régulier, et lisible par le groupe de l’utilisateur web. Si vous voyez wp-config.php -> /some/path, confirmez que la cible existe.

Décision : S’il manque ou est illisible, corrigez le chemin/les permissions avant toute autre chose. WordPress ne peut pas « contourner » une config manquante.

Tâche 2 : Vérifier les permissions (et attraper le piège « utilisateur SSH vs utilisateur PHP »)

cr0x@server:~$ namei -l /var/www/html/wp-config.php
f: /var/www/html/wp-config.php
drwxr-xr-x root     root     /
drwxr-xr-x root     root     var
drwxr-xr-x root     root     www
drwxr-xr-x root     root     html
-rw-r----- www-data www-data wp-config.php

Ce que cela signifie : Les bits d’exécution des répertoires permettent la traversée ; le fichier final est lisible. Si un répertoire du chemin n’a pas le bit exécution pour l’utilisateur PHP, PHP ne peut pas atteindre le fichier.

Décision : Corrigez les permissions de traversée des répertoires plutôt que de « chmod 777 » quoi que ce soit. Si vous envisagez 777, allez prendre un café et faites-le correctement ensuite.

Tâche 3 : Valider que wp-config.php n’a pas d’erreurs de parsing PHP

cr0x@server:~$ php -l /var/www/html/wp-config.php
No syntax errors detected in /var/www/html/wp-config.php

Ce que cela signifie : PHP peut le parser. Échecs courants : BOM errant, point-virgule manquant, guillemets typographiques collés depuis un ticket, ou un <?php en trop.

Décision : Si des erreurs de syntaxe apparaissent, corrigez-les d’abord. Tout le reste est du bruit tant que le parsing ne réussit pas.

Tâche 4 : Confirmer que les constantes DB sont présentes (sans afficher les secrets en masse)

cr0x@server:~$ sudo -u www-data php -r 'include "/var/www/html/wp-config.php"; echo DB_NAME, "\n", DB_HOST, "\n";'
wordpress_prod
db01.internal

Ce que cela signifie : La config se charge sous le même utilisateur que PHP utilise, et les constantes se résolvent. Si l’inclusion échoue, vous verrez des warnings/fatals.

Décision : Si cela échoue, concentrez-vous sur les permissions/chemins/includes. Si cela fonctionne, passez à la vérification réseau/DB.

Tâche 5 : Vérifier la résolution DNS pour DB_HOST

cr0x@server:~$ getent hosts db01.internal
10.20.30.41 db01.internal

Ce que cela signifie : L’hôte se résout. S’il ne se résout pas, WordPress peut tenter et échouer en boucle, surchargeant les workers PHP.

Décision : Si DNS échoue, corrigez DNS/le fichier hosts, ou utilisez une IP temporairement (avec un plan pour revenir en arrière). Ne « réparez » pas WordPress quand c’est en réalité DNS.

Tâche 6 : Vérifier la connectivité TCP vers le port de la base

cr0x@server:~$ nc -vz db01.internal 3306
Connection to db01.internal 3306 port [tcp/mysql] succeeded!

Ce que cela signifie : Le chemin réseau est ouvert. Si vous obtenez des timeouts/refus, c’est un pare-feu, un groupe de sécurité, une DB down, ou un mauvais port.

Décision : Si TCP échoue, ne révoquez pas les mots de passe DB. Réparez d’abord l’atteignabilité réseau.

Tâche 7 : Authentifier sur MySQL avec les mêmes identifiants que WordPress utilise

cr0x@server:~$ mysql -h db01.internal -u wp_user -p -e "SELECT 1;"
Enter password:
1
1

Ce que cela signifie : Les identifiants fonctionnent et le serveur DB répond. Si l’authentification échoue, le message d’erreur est précieux : « Access denied », « Unknown database », etc.

Décision : Si l’auth échoue, vérifiez DB_USER, DB_PASSWORD et les grants. Si le nom de la base est faux, corrigez DB_NAME plutôt que de créer un schéma vide « pour que ça marche ».

Tâche 8 : Identifier le schéma/hôte de la requête depuis le bord (sanité reverse proxy)

cr0x@server:~$ curl -I http://127.0.0.1 | sed -n '1,10p'
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 27 Dec 2025 10:20:04 GMT
Content-Type: text/html
Content-Length: 162
Location: https://example.com/

Ce que cela signifie : Vous voyez une redirection. Si vous êtes derrière un proxy qui termine TLS, l’origine peut penser qu’elle est en HTTP et rediriger incorrectement.

Décision : Si vous avez des boucles de redirection, vérifiez WP_HOME/WP_SITEURL et la gestion des en-têtes du proxy avant de toucher aux plugins.

Tâche 9 : Vérifier la boucle de redirection depuis l’hôte public

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-admin/ | sed -n '1,12p'
HTTP/2 302
date: Sat, 27 Dec 2025 10:21:11 GMT
content-type: text/html; charset=UTF-8
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Un flux d’admin normal redirige vers la page de connexion. Si vous rebondissez sans cesse entre http/https ou différents hôtes, la config ment sur l’URL canonique.

Décision : Corrigez les URLs canoniques dans la config (ou la DB) et corrigez la détection du schéma du proxy. Ne « résolvez » pas avec un plugin de redirection au hasard.

Tâche 10 : Confirmer le mode debug et si les logs croissent

cr0x@server:~$ grep -nE "WP_DEBUG|WP_DEBUG_LOG|WP_DEBUG_DISPLAY" /var/www/html/wp-config.php
92:define('WP_DEBUG', false);
93:define('WP_DEBUG_LOG', true);
94:define('WP_DEBUG_DISPLAY', false);

Ce que cela signifie : Le debug est désactivé, mais la journalisation est activée. Cette combinaison est parfois intentionnelle, mais peut quand même écrire beaucoup si des plugins génèrent des notices.

Décision : Si l’utilisation disque augmente, corrigez le code bruyant ou désactivez la journalisation de debug en production et routez les erreurs vers PHP-FPM/syslog avec une rotation appropriée.

Tâche 11 : Surveiller la taille des logs et la pression de rotation (le coup de cœur des ingénieurs stockage)

cr0x@server:~$ sudo du -sh /var/www/html/wp-content/debug.log
3.6G	/var/www/html/wp-content/debug.log

Ce que cela signifie : Ce fichier est énorme. Sur un petit volume root, c’est comme ça que « le site est down » devient « le serveur est down ».

Décision : Si le log est volumineux, arrêtez l’amplification des écritures : désactivez la journalisation debug, tronquez en sécurité, et ajoutez une rotation. Investiguer pourquoi il a grossi (souvent une seule notice répétée dans un chemin chaud).

Tâche 12 : Vérifier l’espace libre sur le système de fichiers (car les erreurs de config se répercutent sur les disques)

cr0x@server:~$ df -h /var/www
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  600M  99% /

Ce que cela signifie : Vous êtes à un déploiement de la panne. À 99%, MySQL et PHP-FPM commencent à échouer de façons créatives.

Décision : Libérez de l’espace immédiatement (logs, anciennes releases, caches), puis corrigez la cause sous-jacente (souvent des logs de debug, des sauvegardes stockées sur le même volume, ou des répertoires de cache en fuite).

Tâche 13 : Vérifier le drop-in du cache d’objets et si WordPress tente de l’utiliser

cr0x@server:~$ ls -la /var/www/html/wp-content/object-cache.php
-rw-r--r-- 1 www-data www-data 14523 Dec 27 09:42 /var/www/html/wp-content/object-cache.php

Ce que cela signifie : Un drop-in existe. Cela signifie que WordPress le chargera tôt. S’il est cassé ou pointe vers un hôte Redis mort, vous pouvez avoir un admin lent, des échecs de connexion, ou des erreurs fatales.

Décision : Si vous suspectez des problèmes de cache, déplacez-le temporairement (renommez le fichier) pendant une fenêtre de maintenance et retestez.

Tâche 14 : Tester la connectivité Redis (si vous l’avez configuré dans wp-config.php)

cr0x@server:~$ redis-cli -h 127.0.0.1 ping
PONG

Ce que cela signifie : Redis est joignable et répond. Si vous obtenez un timeout, il est soit down, écoute ailleurs, protégé par ACL, ou bloqué par un pare-feu.

Décision : Si Redis est inatteignable, désactivez l’intégration du cache d’objets jusqu’à ce que ce soit réparé. Des caches cassés sont pires que pas de cache.

Tâche 15 : Confirmer la limite mémoire PHP et si WordPress la surcharge

cr0x@server:~$ php -i | grep -i "^memory_limit"
memory_limit => 256M => 256M

Ce que cela signifie : La limite mémoire de base de PHP est 256M. WordPress peut demander plus via des constantes comme WP_MEMORY_LIMIT, mais il ne peut pas dépasser le plafond dur de PHP si celui-ci est configuré ainsi.

Décision : Si vous voyez « Allowed memory size exhausted », augmentez la limite de PHP-FPM (puis identifiez ce qui consomme la mémoire ; n’augmentez pas indéfiniment).

Tâche 16 : Valider les URLs canoniques WordPress dans la base quand la config ne les définit pas

cr0x@server:~$ mysql -h db01.internal -u wp_user -p -D wordpress_prod -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
Enter password:
option_name	option_value
home	https://example.com
siteurl	https://example.com

Ce que cela signifie : Les valeurs DB sont cohérentes. Si elles diffèrent (ou contiennent le mauvais hôte/schéma), vous obtenez des boucles de redirection, des URLs d’assets cassées et de la douleur en admin.

Décision : Si elles sont incorrectes, corrigez-les soigneusement. Préférez une mise à jour contrôlée puis videz les caches. Ne « durcissez » pas temporairement des constantes et ne les oubliez pas pendant des années.

Tâche 17 : Vérifier le comportement cron si DISABLE_WP_CRON est défini

cr0x@server:~$ grep -n "DISABLE_WP_CRON" /var/www/html/wp-config.php
110:define('DISABLE_WP_CRON', true);

Ce que cela signifie : WP-Cron est désactivé. C’est acceptable uniquement si vous avez un vrai cron système appelant wp-cron.php.

Décision : Si vous n’avez pas de cron système, réactivez WP-Cron ou ajoutez immédiatement un job cron. Sinon, les publications programmées, nettoyages et tâches de fond restent en attente sans bruit.

Erreurs courantes : symptômes → cause racine → correctif

Cette section est celle à laquelle vous reviendrez à 02:00. Elle est conçue pour faire correspondre ce que vous voyez à ce qui est réellement défaillant, puis vous donner un correctif concret.

1) Écran blanc / HTTP 500 juste après avoir édité wp-config.php

Symptômes : Page vide, erreur 500, ou « There has been a critical error » immédiatement après un changement de config.

Cause racine : Erreur de syntaxe PHP (point-virgule manquant, guillemet errant), BOM au début du fichier, ou balises <?php en double.

Correctif : Lancez php -l sur le fichier ; revenez à la dernière version connue bonne. Si vous avez copié/collé depuis un ticket, vérifiez les « smart quotes ».

2) « Error establishing a database connection »

Symptômes : Le front-end et l’admin montrent la page d’erreur DB ; les checks de santé échouent.

Cause racine : DB_HOST incorrect, identifiants erronés, privilèges manquants, problème de résolution DNS, ou serveur DB down.

Correctif : Prouvez la connectivité réseau (nc) et authentifiez-vous avec mysql en utilisant les mêmes identifiants. Ne changez les credentials qu’après avoir confirmé que la DB est joignable et saine.

3) Boucles de redirection (surtout après l’ajout d’un reverse proxy/CDN)

Symptômes : Le navigateur indique « trop de redirections », la connexion admin rebondit sans fin, ou HTTP/HTTPS s’inverse en permanence.

Cause racine : WordPress croit que les requêtes sont en HTTP alors qu’elles sont en HTTPS au bord ; WP_HOME/WP_SITEURL désaccordés ; en-têtes proxy non approuvés.

Correctif : Définissez des URLs canoniques de façon cohérente et traitez HTTP_X_FORWARDED_PROTO seulement quand il provient de proxies de confiance. Ne faites pas confiance aveuglément aux en-têtes forwardés venant d’Internet.

4) Avertissements de contenu mixte et CSS/JS cassés

Symptômes : Les pages se chargent mais les assets sont bloqués ; l’admin est non stylé ; la console affiche des erreurs de contenu mixte.

Cause racine : siteurl/home ou WP_HOME/WP_SITEURL en http:// alors que le site est servi via https://.

Correctif : Standardisez sur HTTPS dans la config et la DB. Si vous êtes derrière un proxy, corrigez la détection du schéma pour que WordPress génère des URLs en HTTPS.

5) Infos de debug qui fuitent dans les pages

Symptômes : Les visiteurs voient warnings/notices ; le HTML inclut des chemins de fichiers et des détails de requête.

Cause racine : WP_DEBUG activé avec WP_DEBUG_DISPLAY activé, ou display_errors PHP activé au niveau FPM.

Correctif : En production : WP_DEBUG false, WP_DEBUG_DISPLAY false. Journalisez ailleurs avec rotation. Si vous avez besoin de debug, activez-le temporairement et limitez la durée.

6) Le disque se remplit de façon inattendue

Symptômes : Le serveur devient en lecture seule ou les services plantent ; df affiche 95–100% d’utilisation.

Cause racine : WP_DEBUG_LOG générant un énorme wp-content/debug.log ; plugin spammant des notices ; ou cache mal configuré écrivant sans fin.

Correctif : Arrêtez la croissance du log (désactivez le debug log), tronquez le fichier en sécurité, ajoutez une rotation, et corrigez le code bruyant sous-jacent.

7) Cookies de connexion invalides ou sessions admin qui expirent aléatoirement

Symptômes : Vous vous connectez puis êtes immédiatement déconnecté ; « Are you sure you want to do this? » nonces échouent.

Cause racine : Changer les salts/keys (ou les faire tourner trop agressivement), COOKIE_DOMAIN incohérent, reverse proxy provoquant des changements d’hôte, ou cache des pages admin.

Correctif : Gardez les salts stables sauf si vous invalidez volontairement les sessions. Ne mettez pas en cache /wp-admin ou les pages connectées au bord. Assurez un seul hôte canonique et un domaine de cookie cohérent.

8) Cache d’objets activé mais la perf se dégrade

Symptômes : TTFB plus élevé, CPU en hausse, admin lent ; erreurs intermittentes dans les logs provenant du backend cache.

Cause racine : Redis/Memcached injoignable/lent, mauvais socket/hôte, mismatch d’authentification, ou drop-in de cache incompatible avec la version de PHP.

Correctif : Validez la connectivité du backend, mesurez la latence, et désactivez le drop-in jusqu’à ce qu’il soit stable. Un cache qui laisse filer avec des timeouts est une auto-attaque DoS.

9) Multisite se comporte étrangement après une migration

Symptômes : Sous-sites redirigent mal ; uploads manquants ; admin réseau cassé.

Cause racine : Constantes multisite décalées (MULTISITE, SUBDOMAIN_INSTALL, DOMAIN_CURRENT_SITE, constantes de chemin), ou URLs DB obsolètes.

Correctif : Traitez la config multisite comme une unité. Validez les constantes domaine/chemin par rapport à la DB et au routage du reverse proxy.

10) Régression de sécurité : identifiants DB exposés ou config modifiable

Symptômes : Identifiants découverts dans un repo, des backups, ou des fichiers lisibles publiquement ; malware modifiant la config.

Cause racine : Permissions faibles, secrets commis, ou config dans le document root avec serveur mal configuré autorisant le téléchargement du source (rare mais catastrophique).

Correctif : Verrouillez les permissions, gardez les secrets hors des repos, envisagez de déplacer wp-config.php un répertoire au-dessus, et vérifiez que le serveur ne sert jamais le code PHP source.

Blague 2 : Laisser WP_DEBUG activé en production, c’est comme laisser le capot de votre voiture ouvert pour « améliorer le refroidissement ». Vous entendrez de nouveaux bruits.

Trois mini-récits d’entreprise en production

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise migré WordPress d’une VM unique vers une « vraie » architecture : une base managée, un load balancer et deux nœuds applicatifs. Le plan de migration semblait solide. Le changement de config paraissait anodin : définir DB_HOST sur l’endpoint DB managé et déployer.

L’incident est survenu en quelques minutes. Les deux nœuds retournaient « Error establishing a database connection. » Quelqu’un jurait que les identifiants étaient corrects parce qu’ils « marchaient sur leur portable ». Cette phrase devrait être collée sur un avertissement et attachée à tous les téléphones d’astreinte.

La cause racine n’était pas le mot de passe. C’était la résolution de noms à l’intérieur du VPC. L’endpoint DB managé se résolvait en une adresse privée, mais les nœuds applicatifs utilisaient un résolveur différent qui ne connaissait pas cette zone privée. L’endpoint ne se résolvait pas de façon cohérente, donc les workers PHP s’empilaient en réessayant les connexions. Les checks de santé échouèrent. Le load balancer draina les nœuds. Panne totale, même si « la DB est up ».

Le correctif fut banal : corriger la configuration DNS et tester la résolution depuis le sous-réseau applicatif avant tout changement de config. Ils ajoutèrent un script preflight qui exécute getent hosts et un test de connexion TCP depuis chaque nœud pendant le déploiement. La migration suivante se déroula sans accroc, parce qu’ils arrêtèrent de supposer que « DNS va juste fonctionner ».

Mini-récit 2 : L’optimisation qui a mal tourné

Une poussée performance arriva avec la musique executive habituelle : « Il faut que le site soit plus rapide. » L’équipe ajouta un caching objet Redis. Raisonnable. Ils ajoutèrent le drop-in, définissent WP_CACHE, et un hôte Redis dans la config. Les tests de charge s’améliorèrent. Tout le monde se félicita.

Puis le trafic de production frappa. La latence empirait, pas diminuait. Le CPU monta sur les nœuds applicatifs. Le nombre de workers PHP grimpa. La charge DB baissa, ce qui avait l’air bien jusqu’à ce qu’on note que le site était plus lent. Une de ces semaines « nous avons optimisé la mauvaise chose ».

Le vrai problème : Redis était joignable, mais se trouvait derrière un saut réseau qui introduisait des pics de latence occasionnels. Le drop-in object-cache était configuré avec un timeout de connexion généreux en termes humains et désastreux pour le chemin de requête. Quand Redis se bloquait, chaque requête attendait. Pire, la pénalité de miss déclenchait plus de travail PHP pendant que les workers attendaient sur le cache. Voilà comment le « cache » devient un mécanisme de throttling distribué.

Le correctif fut de traiter Redis comme une infrastructure de production, pas une case à cocher plugin. Ils rapprochèrent Redis (ou le placèrent dans le même niveau réseau), resserrèrent les timeouts et monitorèrent la latence du cache comme s’il s’agissait d’une base de données. Quand Redis était malsain, ils préférèrent un échec rapide plutôt qu’un attente prolongée. Les gains de performance revinrent — parce que le cache cessa d’être la dépendance la plus lente.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe gérait WordPress comme une propriété critique pour le chiffre d’affaires. Ils n’étaient pas tape-à-l’œil. Ils étaient méticuleux. Chaque changement de config était déployé via une pipeline qui exécutait trois vérifications : lint de syntaxe, vérification des permissions sous l’utilisateur web, et une sonde de connectivité DB utilisant l’hôte et l’utilisateur configurés.

Un après-midi, une rotation d’identifiants routinière dérailla. Le gestionnaire de secrets a été mis à jour, mais un nœud applicatif n’a pas rafraîchi ses variables d’environnement à cause d’un bug du superviseur de processus. La moitié de la flotte avait les nouveaux identifiants DB, l’autre moitié non. Le symptôme fut moche : échecs de connexion DB intermittents selon le nœud choisi par le load balancer.

La pipeline l’a détecté avant que cela devienne une panne totale. La sonde DB échoua sur un nœud et le déploiement s’arrêta. L’astreinte reçut une erreur claire : « Cannot authenticate with configured credentials from node X. » Ils drainèrent ce nœud, redémarrèrent les services pour prendre les nouvelles variables d’environnement, puis le réintroduisirent. Les clients n’ont rien remarqué.

La leçon n’était pas « utilisez des variables d’environnement ». C’était : testez la config comme la production l’utilise, à chaque fois. Les vérifications ennuyeuses évitent les incidents excitants.

idée paraphrasée — John Allspaw : la fiabilité vient de la conception pour la façon dont les systèmes tombent en panne, pas de l’espoir que des personnes soigneuses n’auront pas d’erreurs.

Listes de contrôle / plan pas à pas

Pas à pas : éditer wp-config.php en production en toute sécurité

1. Faire une copie en préservant les permissions.

   cr0x@server:~$ sudo cp -a /var/www/html/wp-config.php /var/www/html/wp-config.php.bak
   

   Sens : -a préserve mode/propriété/timestamps. Votre rollback ne créera pas un nouveau problème de permissions.

   Décision : Si vous ne pouvez pas le sauvegarder, vous n’êtes pas prêt à l’éditer.

2. Éditez avec un outil qui n’ajoute pas de BOM ni de guillemets typographiques. Utilisez vim, nano, ou un éditeur correct en SSH.
3. Lint avant le reload.

   cr0x@server:~$ php -l /var/www/html/wp-config.php
   No syntax errors detected in /var/www/html/wp-config.php
   

   Décision : Si le lint échoue, revenez immédiatement et rééditez calmement.

4. Validez-le sous l’utilisateur web.

   cr0x@server:~$ sudo -u www-data php -r 'include "/var/www/html/wp-config.php"; echo "loaded\n";'
   loaded
   

   Décision : Si cela échoue, vous avez probablement introduit un problème de chemin/include/permission que votre shell root masque.

5. Frappez un endpoint léger et surveillez les logs. Préférez une requête unique + tail des logs plutôt qu’une rafraîchissement complet de navigateur en masse.

Checklist de durcissement (faites-le, ne discutez pas)

• Permissions de fichier : lisible par PHP, pas lisible par tout le monde. Typique : 640 possédé par www-data ou root avec groupe lisible.
• Déplacer wp-config.php un répertoire au-dessus lorsque votre agencement le permet, pour qu’il ne soit pas dans le document root.
• Désactiver l’affichage des erreurs en production ; journaliser dans un emplacement contrôlé avec rotation.
• Faire tourner les salts intentionnellement (réponse à incident), pas par habitude. Tourner les salts déconnecte tous les utilisateurs et invalide les sessions.
• Ne pas faire confiance aux en-têtes forwardés par défaut. Ne les honorerez que depuis des IPs proxy connues.
• Garder WP_HOME/WP_SITEURL cohérents. Si vous les définissez dans la config, documentez pourquoi et où se trouve la source de vérité.
• Confirmer la stratégie cron : soit WP-Cron activé, soit cron système en place. « Désactivé sans remplacement » n’est pas une stratégie.

Checklist performance (la version qui ne vous sabote pas)

• Mesurez avant d’activer le cache d’objets. Si votre goulot d’étranglement est le CPU PHP ou des plugins lents, Redis ne vous sauvera pas.
• Fixez des timeouts agressifs pour les caches. Un cache qui fige les requêtes est pire que pas de cache.
• Garder le logging de debug désactivé dans les chemins chauds. L’I/O disque n’est pas une quête gratuite annexe.
• Alignez les limites mémoire avec la réalité. Augmentez les limites seulement si vous corrigez aussi la cause (plugins, requêtes massives, pics de traitement d’images).

Ce qu’il faut mettre dans wp-config.php (et ce qu’il ne faut pas)

Paramètres de base de données : corrects, minimaux, testables

Au minimum : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Tout le reste doit être justifié. Ne parsemez pas de constantes expérimentales parce qu’un billet de blog l’a conseillé. Les blogs n’appellent pas d’astreinte.

Sels et clés : ne bricolez pas la crypto

Les auth keys et salts protègent les cookies et les nonces. S’ils changent, les sessions s’invalident. Cela peut être intentionnel pendant une réponse à incident. Cela ne doit pas faire partie d’un déploiement courant. Stockez-les de façon sécurisée et gardez-les stables.

Préfixe de table : pas une panacée de sécurité

Changer $table_prefix depuis wp_ est acceptable, mais ne le survendez pas. C’est une faiblesse de défense en profondeur, pas un bouclier. Faites-le si vous provisionnez une nouvelle installation ou consolidez des bases. Ne le faites pas en panique après une compromission ; concentrez-vous sur la correction des vulnérabilités, la rotation des credentials et la contention forensique.

Reverse proxy et gestion HTTPS : soyez explicite et prudent

Beaucoup d’incidents proviennent d’une ligne qui force HTTPS incorrectement, ou qui fait confiance à X-Forwarded-Proto depuis n’importe qui. Si vous devez surcharger la détection du schéma dans wp-config.php, faites-le avec des allowlists d’IP au niveau du serveur web/proxy, pas avec de l’optimisme dans PHP.

Paramètres de debug : choisissez soit « journalisation sûre » soit « chaos temporaire », pas les deux

En production, le schéma propre est : ne pas afficher les erreurs ; journaliser dans un emplacement contrôlé ; faire tourner les logs ; alerter sur les pics de volume. Si vous avez besoin d’un debug verbeux, limitez la durée et ayez un plan de rollback.

Mises à jour automatiques et modifications de fichiers : comprenez le rayon d’impact

Désactiver les éditions de fichiers et contrôler les updates peut être responsable en environnements régulés. Cela peut aussi vous laisser avec des plugins vulnérables pendant des mois parce que « les mises à jour font peur ». Décidez en fonction de la maturité de votre pipeline de patch, pas de la superstition.

FAQ

1) Puis-je stocker les identifiants DB dans des variables d’environnement plutôt que dans wp-config.php ?

Oui, et c’est souvent meilleur opérationnellement. Vous réduisez le risque de commettre des secrets. Mais vous devez vous assurer que le service PHP-FPM reçoit de façon fiable l’environnement mis à jour au déploiement/redémarrage, et disposer d’un plan de rollback clair.

2) Faut-il que wp-config.php soit possédé par root ou www-data ?

Les deux peuvent être corrects. Possession par root avec lecture de groupe par l’utilisateur PHP est un pattern de durcissement courant. L’essentiel : PHP doit pouvoir le lire ; les attaquants (et utilisateurs aléatoires) ne doivent pas pouvoir l’écrire.

3) Changer $table_prefix en vaut-il la peine pour la sécurité ?

C’est une défense de profondeur mineure, pas un bouclier. Faites-le si vous provisionnez une nouvelle install ou consolidez des bases. Ne le faites pas en réaction panique à une compromission active ; concentrez-vous sur le patching, la rotation des credentials et la contention forensique.

4) Pourquoi mon site fonctionne en front-end mais wp-admin est cassé après des changements de config ?

Les chemins admin sont plus sensibles aux réglages de schéma/hôte/cookie. La mauvaise détection du reverse proxy, des problèmes de domaine cookie, ou des règles de cache qui mis-cachent les réponses connectées touchent souvent wp-admin en premier.

5) Quelle est la manière la plus sûre d’activer le debug brièvement en production ?

Activez la journalisation, pas l’affichage. Limitez la durée et surveillez la croissance des fichiers. Privilégiez la journalisation au niveau PHP-FPM/serveur web avec rotation plutôt que d’écrire dans wp-content/debug.log.

6) Mon « Error establishing a database connection » disparaît si je rafraîchis. Pourquoi ?

Les connexions DB intermittentes signifient généralement des flaps réseau, une instabilité DNS, un nombre max de connexions DB atteint, ou une authentification lente. Cela peut aussi être une surcharge PHP-FPM causant des timeouts. Traitez-le comme un problème d’infrastructure jusqu’à preuve du contraire.

7) Dois-je définir WP_HOME et WP_SITEURL dans wp-config.php ?

Seulement si vous avez une bonne raison (infrastructure immuable, images conteneurisées, ou changements d’environnement fréquents). Si vous les définissez, vous rendez les valeurs DB non pertinentes — documentez cela, sinon la prochaine personne « réparant » la DB n’obtiendra aucun effet.

8) wp-config.php affecte-t-il directement les performances ?

Oui, indirectement. Le logging de debug, la configuration du cache d’objets, les bascules cron et le traitement SSL peuvent tous modifier la latence et la charge. Un seul timeout de cache mal configuré peut devenir la dépendance la plus lente de chaque requête.

9) Comment éviter de faire tomber le site en éditant wp-config.php ?

Sauvegardez, lint, testez sous l’utilisateur web, et déployez via un chemin contrôlé. Et si possible, utilisez un nœud canari derrière le load balancer pour les changements de config.

Étapes suivantes pour éviter la récurrence des incidents

Si vos pannes WordPress ont un best-of, wp-config.php est probablement la piste numéro un. Les correctifs ne sont pas exotiques. Ils sont disciplinés.

1. Transformez votre « diagnostic rapide » en runbook. Syntaxe, permissions, atteignabilité DB, exactitude schéma/hôte, bascules debug/caching.
2. Ajoutez des vérifications preflight au déploiement. Lint de la config, inclure sous l’utilisateur PHP, et exécuter une sonde de connexion DB utilisant l’hôte et l’utilisateur configurés.
3. Rendez la journalisation sûre par défaut. Pas d’affichage debug en production. Rotation des logs. Alertes sur la croissance des logs et l’utilisation disque.
4. Soyez conservateurs avec les changements de cache. Validez la latence du backend de cache et fixez des timeouts qui échouent vite.
5. Documentez l’URL canonique et le comportement du proxy. La plupart des boucles de redirection sont une ambiguïté de politique qui se fait passer pour un bug.

Faites cela, et wp-config.php redeviendra ce qu’il doit être : un fichier ennuyeux auquel vous pensez rarement. L’ennui, c’est bien. L’ennui scale.