Avant de lire la suite, deux conditions. Vous avez une sauvegarde complète et récente, prise selon la méthode décrite ici. Vous avez un accès FTP ou SFTP.

Sans ça, fermez cet article. Une erreur de syntaxe dans wp-config.php met le site hors ligne instantanément, et l'administration WordPress ne sera plus accessible pour corriger.

Maintenant, on peut y aller.

Où se trouve wp-config.php et à quoi il sert

À la racine de votre installation, à côté des dossiers wp-admin, wp-includes et wp-content.

Si cette arborescence ne vous dit rien, l'article comment est fait un site WordPress pose les bases.

WordPress accepte aussi de le trouver un cran au-dessus de la racine, dans le dossier parent. C'est une pratique de sécurité courante : le fichier sort de l'espace accessible en HTTP tout en restant lisible par PHP.

Son rôle : il est chargé avant tout le reste. Avant le thème, avant les extensions, avant même le cœur de WordPress. C'est pour ça que les réglages qu'on y place s'imposent à tout le système.

Il contient les identifiants de connexion à votre base de données. Voilà pourquoi il ne se partage pas, ne se pousse pas sur un dépôt Git public, et ne se laisse pas traîner dans un dossier de sauvegarde accessible.

Ce qu'il contient par défaut

Quatre blocs.

Les identifiants de base : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Ils viennent de votre hébergeur. Si l'un des quatre est faux, vous obtenez l'écran « Erreur de connexion à la base de données ».

Les clés d'authentification et de salage : huit constantes, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs quatre équivalents en _SALT. Elles chiffrent les informations stockées dans les cookies de session.

Le préfixe des tables : $table_prefix, wp_ par défaut.

Le mode debug : WP_DEBUG, à false sur une installation propre.

Et une ligne à repérer :

/* C'est tout, ne touchez pas à ce qui suit ! Bon blogging ! */

Toute constante ajoutée doit se placer au-dessus de cette ligne. En dessous, elle est ignorée. C'est l'erreur la plus fréquente chez ceux qui suivent un tutoriel sans regarder où ils collent.

Les constantes qui agissent sur la vitesse

C'est la partie qui intéresse tout le monde et que personne ne relie à wp-config.php.

WP_CACHE

define( 'WP_CACHE', true );

WP Rocket écrit cette ligne lui-même à l'activation. Si elle disparaît, souvent après une migration ou une restauration partielle, le cache page ne se déclenche plus. Le plugin reste actif dans l'interface, les réglages sont là, et le site est lent. C'est un des premiers points que je vérifie sur un site qui a WP Rocket installé et qui plafonne en dessous de 50 sur PageSpeed, avant d'engager une optimisation de la vitesse WordPress complète.

Les révisions et l'enregistrement automatique

WordPress crée une révision à chaque enregistrement d'un article. Sans limite, une page retravaillée trente fois occupe trente et une entrées dans la table wp_posts.

define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );
define( 'EMPTY_TRASH_DAYS', 15 );

La première limite les révisions conservées. La deuxième espace les brouillons automatiques, dont l'intervalle est de 60 secondes par défaut. La troisième vide la corbeille au bout de quinze jours au lieu de trente.

Ces réglages ne rendront pas votre site rapide. Ils empêchent la table wp_posts de gonfler pour rien, et sur un site éditorial actif depuis trois ans, la différence est visible. Le mécanisme complet est détaillé dans l'article sur la base de données WordPress.

La mémoire PHP

define( 'WP_MEMORY_LIMIT', '256M' );

La limite par défaut de WordPress est volontairement basse. Sur un site avec Divi, WooCommerce et une quinzaine d'extensions, elle se heurte au plafond et produit une erreur de mémoire épuisée, souvent sur les pages d'administration ou les imports.

Cette constante ne peut pas dépasser la limite fixée par votre hébergeur. Si la valeur ne prend pas, c'est côté serveur qu'il faut regarder.

Les constantes qui agissent sur la sécurité

Bloquer l'éditeur de code intégré

define( 'DISALLOW_FILE_EDIT', true );

Par défaut, un compte administrateur peut modifier les fichiers du thème et des extensions depuis l'interface WordPress. Un compte administrateur compromis devient alors une porte d'entrée directe pour injecter du code sur le serveur.

Cette ligne fait partie de ce que j'applique par défaut sur les sites que je livre et sur ceux couverts par un contrat de maintenance WordPress. Elle ne gêne personne, l'édition de fichiers passe par le FTP.

Renouveler les clés de salage

Elles se génèrent sur le service officiel de WordPress :

https://api.wordpress.org/secret-key/1.1/salt/

Vous remplacez les huit lignes existantes par les huit nouvelles. Effet immédiat : toutes les sessions ouvertes sont invalidées, y compris celles d'un intrus. C'est le premier geste à faire après un piratage, avant même le nettoyage.

Forcer le HTTPS sur l'administration

define( 'FORCE_SSL_ADMIN', true );

Le préfixe des tables

Changer wp_ en autre chose est parfois présenté comme une mesure de sécurité. C'est de la sécurité par l'obscurité : ça gêne les scripts d'attaque automatisés les plus paresseux, et ça n'arrête personne d'autre. À faire à l'installation si vous voulez, jamais après coup sur un site en production, parce que le changement impose de modifier aussi des valeurs à l'intérieur des tables wp_options et wp_usermeta.

Le mode debug : utile en développement, dangereux en production

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Cette combinaison enregistre les erreurs dans wp-content/debug.log sans les afficher aux visiteurs. C'est le réglage à utiliser quand vous cherchez la cause d'une page blanche.

Laisser WP_DEBUG_DISPLAY à true sur un site en ligne affiche les chemins absolus de votre serveur et les noms de vos fichiers à quiconque déclenche une erreur. C'est un cadeau pour un attaquant.

Et repassez WP_DEBUG à false une fois le problème réglé. Le fichier de log grossit sans limite tant qu'il est actif.

Les quatre erreurs qui cassent un site

L'espace avant <?php. Un seul caractère avant la balise d'ouverture, même invisible, provoque une erreur d'en-têtes déjà envoyés. Ça arrive quand on édite le fichier avec un traitement de texte au lieu d'un éditeur de code.

Le point-virgule oublié. Erreur de syntaxe PHP, site hors ligne, écran blanc.

La constante placée sous la ligne « C'est tout ». Aucun effet, et des heures perdues à chercher pourquoi.

L'édition sans copie de secours. Avant toute modification, dupliquez le fichier en wp-config-backup.php sur votre poste, pas sur le serveur. Si le site tombe, vous remontez l'original en trente secondes.

Un dernier point : éditez toujours avec un éditeur de code (VS Code, Notepad++, Sublime), jamais avec Word ou TextEdit, qui ajoutent des caractères invisibles et cassent l'encodage.

FAQ

---

Ce qu'il faut retenir

• Sauvegarde et accès FTP avant toute modification, sans exception.
• Les constantes ajoutées se placent au-dessus de la ligne « That's all ».
• WP_CACHE disparu après une migration explique beaucoup de sites lents malgré WP Rocket.
• WP_DEBUG_DISPLAY à true en production expose l'arborescence de votre serveur.

Sur un site de boulangerie ou de pâtisserie qui prend des commandes en ligne, une page blanche un vendredi soir coûte un week-end de chiffre d'affaires.

Ce fichier pilote la vitesse et la sécurité de votre site depuis une vingtaine de lignes. Ça vaut dix minutes de vérification.