- Site WordPress
Fichier wp-config.php : le guide complet

Article publié par Kévin
ÉvidenceWP accompagne les entreprises qui souhaitent faire de leur présence en ligne un véritable levier commercial.
Découvrez les offres de conception de site WordPress professionnel, les forfaits de maintenance WordPress et l’accompagnement SEO sur mesure, et bénéficiez d’un site conçu pour générer des demandes, des réservations ou des ventes de façon pérenne.
Réservez un appel découverte gratuit pour échanger sur votre projet et identifier la solution la plus adaptée.
wp-config.php est le fichier de configuration de WordPress, celui qui contient les identifiants de connexion à votre base de données, et qui protège vos connexions et vos formulaires avec ses propres clés secrètes. Une seule ligne mal écrite à l’intérieur, et c’est l’ensemble du site qui s’arrête net.
Ce fichier mérite d’être démystifié plutôt que de rester intimidant. Une fois qu’on comprend sa logique, le localiser sur son site, le sécuriser, le modifier sans rien casser, ou en générer un nouveau quand l’ancien a disparu, devient à la portée de n’importe quel propriétaire de site, pas seulement d’un développeur.
Dans ce guide, je vous montre exactement quelles informations il contient, où le trouver, comment le modifier et le sécuriser, comment le générer si besoin, et comment résoudre les erreurs les plus courantes qui lui sont liées. Vous n’avez besoin d’aucune compétence de développeur pour suivre ce qui va suivre, seulement de la méthode, et je vous la donne pas à pas.
L’essentiel à retenir sur le fichier wp-config.php
Si vous deviez toucher au fichier wp-config.php, seriez-vous en mesure de maîtriser votre intervention ?
Qu’est-ce que le fichier wp-config.php et à quoi sert-il ?
Le fichier wp-config.php est le fichier de configuration central de votre site WordPress. Il contient les informations qui permettent à WordPress de se connecter à sa base de données, et regroupe les réglages essentiels à son fonctionnement.
WordPress en personne le présente comme l’un des fichiers les plus importants de toute l’installation.
Je le compare souvent au tableau électrique d’une maison. Vous ne l’ouvrez presque jamais, mais c’est lui qui distribue et sécurise tout ce qui fait fonctionner l’installation. Et le jour où quelque chose ne tourne pas rond, c’est le premier endroit où l’on va regarder.
Les cinq grandes missions du fichier wp-config.php
Ne vous fiez pas à sa taille modeste, ce fichier assure cinq missions à lui seul, toute d’une grande utilité et aucune n’est secondaire :
Pas d’inquiétude si certains de ces termes restent encore un peu abstraits pour l’instant. Je détaille chacun d’entre eux juste après, afin que vous compreniez exactement à quoi sert chaque ligne de ce fichier.
Un fichier à part dans votre installation
Trois caractéristiques font du fichier wp-config.php une pièce à part :
Ce dernier point est important, car il révèle que wp-config.php est l’un des rares endroits de votre installation qui vous appartient vraiment, et qui ne subit pas de changements au fil du temps à l’exception de ceux que vous mettrez en place vous même.
À SAVOIR : vous n’avez pas besoin de maîtriser chaque ligne de ce fichier pour être un propriétaire de site sérieux. Savoir qu’il existe, comprendre ce qu’il gouverne et reconnaître le moment où une intervention devient nécessaire, c’est déjà l’essentiel.
Où se trouve le fichier wp-config.php sur votre site ?
Maintenant que vous savez ce qu’est ce fichier et à quoi il sert, reste à savoir comment le localiser concrètement sur votre site.wp-config.php se trouve à la racine de votre installation WordPress, le dossier de départ qui contient tous les autres, celui que WordPress désigne techniquement par ABSPATH.
Il partage cet emplacement avec les dossiers wp-admin, wp-content et wp-includes, ainsi qu’avec d’autres fichiers du cœur de WordPress comme wp-settings.php, wp-login.php, ou encore son propre modèle wp-config-sample.php, dont je vous reparlerai plus loin dans l’article.
Deux méthodes permettent d’y accéder :

Dans les deux cas, vous retrouverez exactement la même liste de fichiers et de dossiers, celle de la racine de votre site.

Quelles informations contient le fichier wp-config.php ?
Vous savez maintenant ce qu’est ce fichier et où le trouver sur votre site. Voici le détail complet des informations qu’il contient réellement, mission par mission.
Les identifiants de connexion à la base de données
Quatre informations permettent à WordPress de se connecter à votre base de données.
Ces quatre informations sont en partie secrètes, votre mot de passe en particulier ne doit jamais être partagé ni publié nulle part.
À SAVOIR : deux réglages supplémentaires accompagnent ces identifiants, DB_CHARSET et DB_COLLATE, et méritent une explication à part, car ce sont deux notions souvent mal comprises.
Les clés et sels de sécurité
Le fichier contient quatre clés, chacune accompagnée de son propre sel qui la renforce, soit quatre paires en tout.
Trois de ces paires sécurisent les cookies de connexion de vos utilisateurs, ces petits fichiers déposés dans leur navigateur pour les maintenir connectés, et empêchent qu’ils soient falsifiés.
La quatrième, NONCE_KEY et NONCE_SALT, protège vos formulaires et certaines actions du tableau de bord en vérifiant que chaque requête provient bien de votre site.
ABSPATH, le chemin absolu vers le dossier WordPress
Cette constante tire son nom de « absolute path », chemin absolu en français, WordPress la définit dans le fichier avec le commentaire « Absolute path to the WordPress directory », chemin absolu vers le dossier WordPress.
Un chemin absolu est l’adresse complète d’un dossier sur le serveur, écrite depuis le tout début de l’arborescence, c’est à dire l’organisation des dossiers les uns dans les autres.
Pour faire une simple analogie, c’est la différence entre indiquer sa maison en disant « elle se trouve juste après celle de mon voisin », et donner son adresse postale complète, numéro, rue, ville et code postal, à quelqu’un qui n’a jamais mis les pieds dans le quartier.
Chez o2switch par exemple, ce chemin prend la forme /home/votrecompte/public_html/, « votrecompte » étant l’identifiant unique de votre hébergement.wp-config.php définit lui même où pointe ABSPATH, avec une ligne proche de celle ci, define( 'ABSPATH', __DIR__ . '/' );. __DIR__ signifie le dossier où se trouve le fichier actuel, donc cette ligne dit concrètement à WordPress que ABSPATH correspond au dossier où se trouve wp-config.php lui même, c’est à dire la racine de votre installation, le dossier de départ qui contient tous les autres.
Ce dossier racine contient trois dossiers essentiels.
La toute dernière ligne de wp-config.php, require_once ABSPATH . 'wp-settings.php';, combine ce chemin avec le nom wp-settings.php pour localiser ce fichier et l’exécuter aussitôt.
WordPress précise que ce fichier prépare tout ce dont le logiciel a besoin pour démarrer et charge l’ensemble de ses fichiers, ce qui revient à allumer le cœur du logiciel. wp-config.php ne range donc pas seulement des réglages, c’est lui qui allume la machine.
ATTENTION : une erreur de syntaxe à cet endroit empêche le fichier de s’exécuter, et le site entier devient inaccessible.
Le préfixe des tables, pourquoi et quand le changer
Une base de données est découpée en tables, l’équivalent d’onglets dans un tableur.
Le préfixe est le texte placé devant le nom de chacune, wp_ par défaut.
Il me semble essentiel de souligner un point sur ce préfixe, qui revient régulièrement dans mes interventions.
Le changer n’est pas qu’une question de goût, c’est aussi une mesure de sécurité, dans le sens où un préfixe personnalisé complique la tâche d’un script automatisé qui cherche à cibler vos tables avec leur nom par défaut.
Mais attention, changer ce préfixe uniquement dans wp-config.php ne suffit pas, il faut aussi renommer les tables concernées directement dans la base de données, sans quoi WordPress ne les retrouve plus et votre site devient inaccessible.
Cette notion, je la détaille en profondeur dans mon guide dédié au préfixe de la base de données WordPress, avec la méthode complète pour le changer sans casser votre site.
L’adresse du site, WP_SITEURL et WP_HOME
Deux constantes distinctes définissent l’adresse de votre site :
Dans la grande majorité des installations, ces deux adresses sont identiques.
Elles peuvent différer si WordPress est installé dans un sous dossier alors que le site doit rester accessible depuis l’adresse racine du domaine.
Ces deux constantes deviennent particulièrement utiles lors d’une migration.
En effet, imaginez que vous transférez votre site vers un nouveau nom de domaine, mais que la base de données garde encore l’ancienne adresse enregistrée.
Sans intervention, WordPress peut alors vous bloquer l’accès à votre tableau de bord, ou créer une boucle de redirection sans fin dans votre navigateur, un scénario que plusieurs hébergeurs documentent comme une cause fréquente d’erreur après une migration.
En définissant WP_SITEURL et WP_HOME directement dans le fichier, vous forcez WordPress à utiliser la bonne adresse immédiatement, même si la base de données n’a pas encore été mise à jour.
Vous retrouvez ainsi l’accès à votre tableau de bord, le temps de corriger la valeur dans votre base de données.
Le mode debug
WP_DEBUG est la constante qui active le mode de débogage de WordPress.
Elle est désactivée par défaut. Deux constantes l’accompagnent, WP_DEBUG_LOG, qui enregistre les erreurs dans un fichier journal, et WP_DEBUG_DISPLAY, qui contrôle si ces erreurs s’affichent directement à l’écran.
Ce réglage a sa place dans ce fichier parce qu’il doit être actif dès le tout début du chargement de votre site, pour détecter les erreurs les plus précoces.
Vous verrez plus loin dans l’article comment l’activer concrètement pour résoudre un problème.
Les autres réglages possibles
Au delà de ce qu’on vient de voir, ce fichier peut accueillir bien d’autres constantes. En voici une bonne partie, regroupées par thème.
Mémoire allouée à PHP
Ces constantes augmentent la mémoire que PHP peut utiliser pour faire fonctionner votre site.
|
Constante |
Rôle |
|---|---|
|
|
Augmenter la mémoire allouée à WordPress, utile en cas d’erreur de mémoire épuisée. |
|
|
Augmenter spécifiquement la mémoire allouée dans l’administration, où les besoins sont souvent plus élevés. |
Organisation des dossiers
Ces constantes permettent de déplacer certains dossiers de WordPress hors de leur emplacement par défaut.
|
Constante |
Rôle |
|---|---|
|
|
Déplacer le dossier |
|
|
Déplacer le dossier des extensions. |
|
|
Déplacer le dossier des fichiers téléversés. |
Contenu et gestion de la base
Ces réglages agissent sur la façon dont WordPress gère vos contenus au fil du temps.
|
Constante |
Rôle |
|---|---|
|
|
Limiter ou désactiver les révisions d’articles. |
|
|
Espacer les enregistrements automatiques. |
|
|
Régler la durée avant suppression définitive de la corbeille. |
Environnement et performance
Ces constantes indiquent à WordPress dans quel contexte il tourne et comment optimiser sa vitesse.
|
Constante |
Rôle |
|---|---|
|
|
Déclarer le site comme local, développement, préproduction ou production. |
|
|
Donner le feu vert à une extension de cache, pour qu’elle puisse accélérer votre site dès le tout début de son chargement. |
Sécurité et administration
Ces réglages renforcent la protection de votre tableau de bord et de vos échanges avec l’extérieur.
|
Constante |
Rôle |
|---|---|
|
|
Désactiver l’éditeur de thème et d’extensions dans le tableau de bord. |
|
|
Bloquer aussi l’installation et la mise à jour depuis le tableau de bord. |
|
|
Forcer le HTTPS sur l’administration. |
|
|
Bloquer les requêtes vers des adresses extérieures non autorisées. |
Mises à jour
Ces constantes vous laissent la main sur la façon dont WordPress se met à jour automatiquement.
|
Constante |
Rôle |
|---|---|
|
|
Désactiver toutes les mises à jour automatiques. |
|
|
Régler le niveau de mise à jour automatique du cœur. |
Réseau de sites
Cette constante concerne les sites qui souhaitent gérer plusieurs sites depuis une seule installation WordPress.
|
Constante |
Rôle |
|---|---|
|
|
Autoriser la création d’un réseau multisite. |
Tâches planifiées
Ces constantes agissent sur le système qui exécute automatiquement certaines actions à intervalles réguliers.
|
Constante |
Rôle |
|---|---|
|
|
Désactiver ou remplacer le système de tâches planifiées de WordPress. |
Comment écrire correctement une nouvelle constante
Les tableaux ci-dessus donnent le rôle de chaque réglage, mais pas encore la façon de l’écrire. Voici la syntaxe à respecter pour en ajouter une sans erreur.
Toute constante suit le même schéma :
1define( 'NOM_DE_LA_CONSTANTE', valeur );
La valeur prend ensuite l’une de ces trois formes :
Chaque ligne se place avant le repère écrit dans le fichier, le commentaire That’s all, stop editing! Happy publishing., qui marque la fin de la zone où vous pouvez ajouter vos propres réglages.
ATTENTION : avant d’enregistrer, vérifiez bien la syntaxe de votre ligne, vous ne devez avoir aucun espace superflu à l’intérieur des guillemets, aucun guillemet oublié autour d’une valeur, et ne devez jamais ajouter de nouvelle constante après la dernière ligne du fichier, elle s’exécuterait trop tard pour avoir le moindre effet, WordPress ayant déjà fini de charger sa configuration à ce moment là.
Un exemple de fichier wp-config.php type
Voici à quoi ressemble un fichier wp-config.php avec les réglages essentiels qu’on vient de détailler, connexion à la base, préfixe, adresse du site, clés de sécurité et mode debug.
1<?php2// ** Reglages de la base de donnees ** //3define( 'DB_NAME', 'nom_de_la_base' );4define( 'DB_USER', 'nom_utilisateur' );5define( 'DB_PASSWORD', 'mot_de_passe' );6define( 'DB_HOST', 'localhost' );7define( 'DB_CHARSET', 'utf8mb4' );8define( 'DB_COLLATE', '' );910$table_prefix = 'wp_';1112define( 'WP_SITEURL', 'https://votresite.fr' );13define( 'WP_HOME', 'https://votresite.fr' );1415define( 'AUTH_KEY', 'votre_cle_unique' );16define( 'SECURE_AUTH_KEY', 'votre_cle_unique' );17define( 'LOGGED_IN_KEY', 'votre_cle_unique' );18define( 'NONCE_KEY', 'votre_cle_unique' );19define( 'AUTH_SALT', 'votre_cle_unique' );20define( 'SECURE_AUTH_SALT', 'votre_cle_unique' );21define( 'LOGGED_IN_SALT', 'votre_cle_unique' );22define( 'NONCE_SALT', 'votre_cle_unique' );2324define( 'WP_DEBUG', false );2526/* That's all, stop editing! Happy publishing. */2728if ( ! defined( 'ABSPATH' ) ) {29 define( 'ABSPATH', __DIR__ . '/' );30}3132require_once ABSPATH . 'wp-settings.php';
Comment modifier le fichier wp-config.php sans casser votre site ?
Vous savez maintenant ce que contient ce fichier et où le trouver. Reste la question qui compte le plus, comment le modifier sans risquer de rendre votre site inaccessible.
Une simple erreur de syntaxe suffit à casser l’installation entière, on l’a vu plus haut, donc la méthode que vous employez compte autant que ce que vous écrivez dedans.
Il me semble essentiel de souligner un point avant d’aller plus loin. Je ne modifie jamais ce fichier directement en ligne, sans filet.
Voici la méthode que j’applique systématiquement pour mon site ou celui de mes clients :


IMPORTANT : voici deux conseils afin de diminuer les risques lorsque vous interviendrez sur le fichier wp-config.php.
Comment sécuriser le fichier wp-config.php ?
Ce fichier concentre à lui seul les informations les plus sensibles de votre site, vos identifiants de base de données et vos clés de sécurité. Le protéger correctement ne demande ni extension supplémentaire ni compétence de développeur, seulement quelques réglages ciblés, que je vous détaille un par un.
Les permissions du fichier
Chaque fichier sur votre serveur possède des permissions, c’est à dire des règles qui définissent qui a le droit de le lire, de le modifier, ou de l’exécuter. Ces réglages jouent un rôle direct dans la façon de protéger et sécuriser votre installation, bien au delà du seul fichier wp-config.php.
Par défaut, ce fichier est créé avec la permission 644, ce qui signifie que n’importe quel autre compte présent sur le même serveur peut le lire. WordPress recommande explicitement de durcir cette permission, en la réglant sur 440 ou 400, pour empêcher les autres utilisateurs du serveur d’y accéder.
C’est la seule exception que WordPress cite explicitement à cette règle des permissions de fichiers, précisément pour empêcher les autres utilisateurs du serveur de le lire.
Pour changer cette permission, la plupart des gestionnaires de fichiers proposent une option « Change Permissions » au clic droit sur le fichier.
Sur cette capture, j’ai effectué l’opération via le cPanel d’o2switch.

Une fenêtre s’ouvre, avec des cases à cocher plutôt qu’un champ où saisir directement un chiffre. Chaque case correspond à une valeur précise, « Lecture » vaut quatre points, « Écriture » vaut deux points, « Exécuter » vaut un point, et ces valeurs s’additionnent pour chaque colonne, « Utilisateur », « Groupe », « Tout le monde ».
C’est cette addition qui donne les trois chiffres du réglage final, 6 pour « Lecture » et « Écriture » combinées, 4 pour « Lecture seule ».

Pour passer de la permission par défaut, 644, à 440, décochez « Écriture » dans la colonne « Utilisateur », puis décochez « Lecture » dans la colonne « Tout le monde ».
Cette interface à cases à cocher est celle du gestionnaire de fichiers cPanel, que j’ai testée chez o2switch. Si vous passez par un client FTP comme FileZilla à la place, vous retrouverez les mêmes cases, mais avec en plus un champ où saisir directement le chiffre si vous le connaissez déjà.
À SAVOIR : sur certaines configurations d’hébergement mutualisé, une permission trop restrictive peut empêcher WordPress lui même d’écrire dans ce fichier lors d’une modification automatique. Si vous constatez un blocage après ce changement, revenez à 644 et contactez votre hébergeur pour connaître la configuration exacte adaptée à votre serveur.
Blocage via .htaccess ou Nginx
Au delà des permissions, vous pouvez aussi empêcher directement toute tentative d’accès à ce fichier depuis un navigateur, en ajoutant une règle à votre serveur web.
Si votre site tourne sur un serveur Apache, comme c’est le cas chez la plupart des hébergeurs mutualisés français, ajoutez ce bloc dans votre fichier .htaccess, à la racine de votre site.
1<Files wp-config.php>2 Require all denied3</Files>
Si votre site tourne sur Nginx, ajoutez plutôt cette règle dans le fichier de configuration de votre serveur.
1location ~* wp-config.php {2 deny all;3}
Cette règle empêche toute personne d’ouvrir directement l’adresse de ce fichier dans un navigateur, sans rien changer à la façon dont WordPress lui même le lit en interne pour fonctionner.
Le débat autour du déplacement du fichier hors de la racine
Une pratique revient régulièrement dans les discussions entre spécialistes WordPress, déplacer physiquement wp-config.php en dehors du dossier public de votre site, puis indiquer à WordPress où aller le chercher.
L’argument en faveur : un fichier situé hors du dossier accessible depuis le web ne peut, en théorie, jamais être atteint par une simple requête de navigateur, même en cas de mauvaise configuration du serveur qui laisserait passer une requête qu’elle aurait dû bloquer.
L’argument contre : ce déplacement ne change rien à la façon dont WordPress lui même continue d’accéder au fichier pour fonctionner, ligne après ligne. Si une faille permet à quelqu’un de lire ou d’inclure des fichiers sur votre serveur, cette même faille lui permet généralement d’atteindre un fichier situé juste au dessus du dossier public, pas seulement ceux qui s’y trouvent. Le problème se déplace, il ne se résout pas.
Ce que la logique technique permet de trancher clairement : une fois qu’un serveur est réellement compromis, au point qu’un attaquant peut lire ou inclure des fichiers à sa guise, la localisation exacte de wp-config.php cesse d’avoir une réelle importance. La vraie protection se joue avant, sur les permissions du fichier et le blocage au niveau du serveur qu’on vient de voir, pas sur l’endroit précis où le fichier est rangé.
Reconnaître un fichier compromis
Un wp-config.php piraté ne s’annonce pas toujours par un site visiblement cassé.
Certains scripts malveillants injectent une ligne discrète, pensée pour passer inaperçue, plutôt que de tout casser d’un coup.
Deux signaux doivent vous alerter :
Voici, à titre d’exemple illustratif uniquement, à quoi ce genre d’ajout peut ressembler dans le fichier.
1eval(base64_decode('...'));
Restaurez plutôt une sauvegarde saine et récente, puis faites appel à un spécialiste pour identifier comment cette ligne s’est retrouvée là avant de remettre le site en ligne.
Une fois le site nettoyé, régénérez aussi les huit clés et sels de sécurité vus plus haut dans cet article.
WordPress met à disposition un générateur officiel à l’adresse api.wordpress.org/secret-key/1.1/salt/, qui produit huit nouvelles lignes aléatoires prêtes à coller.
Il suffit de remplacer les huit lignes existantes dans wp-config.php par ces nouvelles valeurs.
Ce changement invalide les cookies de connexion existants et invalide les jetons de formulaires en cours, ce qui oblige tout le monde à se reconnecter et empêche toute action déjà amorcée par l’intrus de se terminer.
Comment générer ou régénérer un fichier wp-config.php ?
La bonne méthode dépend entièrement de votre situation. Créer un site tout neuf et récupérer un fichier disparu ou corrompu ne demandent pas la même approche, la seconde a besoin d’aller plus vite et plus simplement que la première.
Voici les deux scénarios, chacun avec sa marche à suivre.
Pour l’installation d’un nouveau site
Ce cas de figure concerne une toute première installation, la vôtre ou celle d’un client, sans aucun fichier existant à préserver. Deux méthodes s’offrent à vous, les voici en détail.
Via l’outil d’installation de l’hébergeur ou un logiciel local
Dans l’immense majorité des cas aujourd’hui, vous n’avez rien à faire. Que vous installiez WordPress via l’outil automatique de votre hébergeur ou via un logiciel de développement local comme Local, le principe reste identique, vous saisissez vos informations dans un assistant, et le fichier se crée tout seul derrière, sans que vous ayez besoin d’y toucher.
Chez o2switch, cet outil s’appelle Softaculous. Voici comment y accéder.


En copiant manuellement wp-config-sample.php
Ce scénario se présente généralement à vous dans deux cas de figure :
WordPress le confirme dans son propre code source, la cause vient le plus souvent des permissions du dossier, un réglage proche de celui qu’on a vu plus haut pour sécuriser wp-config.php, mais appliqué ici au dossier entier plutôt qu’à un seul fichier.
Dans ce second cas, WordPress ne vous laisse pas les mains vides, il affiche le contenu complet et déjà rempli de votre futur fichier, identifiants de base de données et nouvelles clés de sécurité inclus, dans une zone de texte prête à copier.
Il ne vous reste alors qu’à créer un nouveau fichier wp-config.php, à y coller ce contenu, puis à l’envoyer à la racine de votre site.
Voici comment procéder vous même à partir du fichier modèle :


Voici à quoi ressemble ce fichier modèle dans son intégralité, tel qu’il est distribué par WordPress aujourd’hui :
1<?php2/**3 * The base configuration for WordPress4 *5 * The wp-config.php creation script uses this file during the installation.6 * You don't have to use the website, you can copy this file to "wp-config.php"7 * and fill in the values.8 *9 * This file contains the following configurations:10 *11 * * Database settings12 * * Secret keys13 * * Database table prefix14 * * ABSPATH15 *16 * @link https://developer.wordpress.org/advanced-administration/wordpress/wp-config/17 *18 * @package WordPress19 */2021// ** Database settings - You can get this info from your web host ** //22/** The name of the database for WordPress */23define( 'DB_NAME', 'database_name_here' );2425/** Database username */26define( 'DB_USER', 'username_here' );2728/** Database password */29define( 'DB_PASSWORD', 'password_here' );3031/** Database hostname */32define( 'DB_HOST', 'localhost' );3334/** Database charset to use in creating database tables. */35define( 'DB_CHARSET', 'utf8mb4' );3637/** The database collate type. Don't change this if in doubt. */38define( 'DB_COLLATE', '' );3940/**#@+41 * Authentication unique keys and salts.42 *43 * Change these to different unique phrases! You can generate these using44 * the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}.45 *46 * You can change these at any point in time to invalidate all existing cookies.47 * This will force all users to have to log in again.48 *49 * @since 2.6.050 */51define( 'AUTH_KEY', 'put your unique phrase here' );52define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );53define( 'LOGGED_IN_KEY', 'put your unique phrase here' );54define( 'NONCE_KEY', 'put your unique phrase here' );55define( 'AUTH_SALT', 'put your unique phrase here' );56define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );57define( 'LOGGED_IN_SALT', 'put your unique phrase here' );58define( 'NONCE_SALT', 'put your unique phrase here' );5960/**#@-*/6162/**63 * WordPress database table prefix.64 *65 * You can have multiple installations in one database if you give each66 * a unique prefix. Only numbers, letters, and underscores please!67 *68 * At the installation time, database tables are created with the specified prefix.69 * Changing this value after WordPress is installed will make your site think70 * it has not been installed.71 *72 * @link https://developer.wordpress.org/advanced-administration/wordpress/wp-config/#table-prefix73 */74$table_prefix = 'wp_';7576/**77 * For developers: WordPress debugging mode.78 *79 * Change this to true to enable the display of notices during development.80 * It is strongly recommended that plugin and theme developers use WP_DEBUG81 * in their development environments.82 *83 * For information on other constants that can be used for debugging,84 * visit the documentation.85 *86 * @link https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/87 */88define( 'WP_DEBUG', false );8990/* Add any custom values between this line and the "stop editing" line. */919293/* That's all, stop editing! Happy publishing. */9495/** Absolute path to the WordPress directory. */96if ( ! defined( 'ABSPATH' ) ) {97 define( 'ABSPATH', __DIR__ . '/' );98}99100/** Sets up WordPress vars and included files. */101require_once ABSPATH . 'wp-settings.php';
Vous pouvez aussi récupérer ce fichier directement sur GitHub en cliquant ici, il s’agit exactement du même contenu, toujours à jour, gratuit, sans aucune donnée à transmettre.
Pour un fichier disparu ou corrompu
Ici, la situation est différente, votre site existait déjà et fonctionnait normalement.
Réinstaller WordPress en entier serait disproportionné et risqué pour le reste de votre contenu. La bonne réponse consiste à comprendre ce qui se passe, puis à réparer uniquement ce qui manque.
Reconnaître le bon symptôme
Un fichier disparu et un fichier corrompu ne se manifestent pas de la même façon, et les confondre peut faire perdre un temps précieux à chercher le mauvais problème.

Dans les deux cas, rassurez vous, votre contenu ne risque rien. La base de données, où sont stockés vos articles, vos pages et vos réglages, reste entièrement intacte, seul le fichier qui permet à WordPress de la retrouver pose problème.
Et même si vous alliez jusqu’au bout de cet assistant par erreur, WordPress refuse de continuer dès qu’il détecte que la base de données contient déjà les tables de votre site, avec un message explicite vous demandant de les vider avant de poursuivre.
Aucun risque donc d’écraser accidentellement votre contenu existant.
La méthode la plus rapide, copier wp-config-sample.php
Pas besoin de passer par l’assistant d’installation, la même méthode déjà détaillée plus haut dans cet article s’applique ici, en partant de wp-config-sample.php, mais avec quelques différences propres à ce contexte de récupération.
À SAVOIR : une alternative existe si vous n’avez pas cette copie sous la main, elle consiste à installer WordPress sur un sous domaine dédié à cet usage, uniquement pour en récupérer un fichier fraîchement généré.
Deux prérequis avant de vous lancer, le sous domaine doit exister sur votre hébergement, et un certificat SSL doit y être installé.
Un point important à connaître avant de vous lancer, changer le mot de passe de connexion à la base de données n’est jamais nécessaire dans ce cas précis, contrairement à un vrai piratage. Il suffit de renseigner dans le nouveau fichier les informations qui existent déjà.
Comment résoudre les erreurs les plus courantes liées au fichier wp-config.php ?
Malgré toutes les précautions qu’on vient de voir, une erreur peut toujours survenir. Voici comment reconnaître et résoudre les trois erreurs les plus fréquentes liées à ce fichier.
L’erreur de connexion à la base de données

C’est l’une des erreurs les plus courantes sur WordPress, et dans l’immense majorité des cas, elle provient directement de ce fichier. Elle signifie que WordPress ne parvient pas à joindre votre base de données, le plus souvent à cause d’une information incorrecte dans les identifiants de connexion.
Ce qu’il faut vérifier en premier, dans l’ordre :
Si après vérification, et modification, tous ces éléments sont corrects et que le problème persiste, un second message peut apparaître à la place du premier, « One or more database tables are unavailable. The database may need to be repaired. »
Ce n’est plus une erreur de connexion, la connexion fonctionne, mais WordPress détecte cette fois que les tables à l’intérieur de la base sont corrompues.
C’est uniquement pour ce second cas précis que l’outil de réparation entre en jeu. Dans ce cas vous pouvez ajouter cette constante dans wp-config.php.
1define( 'WP_ALLOW_REPAIR', true );
Si vous tentez d’accéder à l’adresse {votresite}/wp-admin/maint/repair.php, vous vous retrouverez face à cet écran, et c’est tout à fait normal, WordPress vous demande d’abord d’ajouter la constante affichée sur l’écran pour pouvoir accéder à l’outil de réparation.

Une fois cette ligne enregistrée, rendez vous à l’adresse {votresite}/wp-admin/maint/repair.php. WordPress vous propose alors de réparer, ou de réparer et optimiser votre base de données automatiquement.

IMPORTANT : il me semble essentiel de souligner un point de sécurité avant que vous n’utilisiez cet outil.
Cette page de réparation reste accessible sans connexion, ce qui est logique puisque votre base de données peut être justement ce qui vous empêche de vous connecter, mais ça veut aussi dire que n’importe qui connaissant cette adresse peut y accéder tant que la constante reste active.
Retirez cette ligne de wp-config.php dès que la réparation est terminée.
Le message de mémoire allouée dépassée
Ce message apparaît quand un script dépasse la quantité de mémoire que PHP l’autorise à utiliser, généralement provoqué par une extension gourmande, un thème mal optimisé, ou simplement un site qui a grossi avec le temps.
Et voici le message en question, qui vous parlera d’ailleurs peut-être si vous l’avez déjà rencontré :
Fatal error : Allowed memory size of 268435456 bytes exhausted (tried to allocate X bytes) in [chemin du fichier] on line [numéro]
WordPress tente d’augmenter automatiquement cette limite à 40 Mo pour un site simple, et 64 Mo pour un réseau multisite.
Mais en pratique, ces valeurs restent souvent insuffisantes aujourd’hui, la plupart des sites fonctionnent avec des valeurs plus généreuses, réglées selon ce qu’autorise l’hébergeur, couramment 128M, 256M ou 512M.
Il existe alors deux façons de régler cette limite, et les voici.
Augmenter la mémoire allouée à PHP via l’hébergeur
La première, directement depuis votre hébergeur, si le cPanel ou un outil équivalent est disponible. Chez o2switch, ça se passe dans le sélecteur de version PHP du cPanel.



Je vous montre ici l’exemple précis de l’interface o2switch, en sachant chaque hébergeur a la sienne, mais un hébergement bien pensé propose normalement un outil de ce type pour régler cette limite sans avoir à toucher au code.
Augmenter la mémoire allouée à PHP en plaçant la constante WP_MEMORY_LIMIT dans le fichier wp-config.php
La seconde façon se met en place directement dans wp-config.php, avec la constante WP_MEMORY_LIMIT, déjà vue plus haut dans cet article.
1define( 'WP_MEMORY_LIMIT', '256M' );

IMPORTANT : certains hébergeurs plafonnent la mémoire PHP disponible directement au niveau du serveur.
Dans ce cas, augmenter WP_MEMORY_LIMIT dans wp-config.php ne change rien, puisque WordPress ne peut jamais dépasser ce que le serveur autorise réellement, quelle que soit la valeur indiquée dans le fichier. Si l’erreur persiste après avoir augmenté cette constante, contactez votre hébergeur pour vérifier ce plafond.
Une dernière constante existe, WP_MAX_MEMORY_LIMIT, qui augmente spécifiquement la mémoire allouée dans l’administration, où les besoins sont souvent plus élevés que sur la partie publique du site, déjà vue plus haut dans cet article.
Activer le mode debug pour identifier une erreur PHP
Le mode debug ne résout jamais une erreur à lui seul, il sert à la révéler.
Concrètement, WordPress fonctionne normalement en cachant ses petits problèmes internes, notices et avertissements qui n’empêchent pas le site de fonctionner mais qui signalent quand même quelque chose d’imparfait dans le code d’une extension ou d’un thème.
Le mode debug lève ce voile, pour que vous, ou la personne qui vous accompagne, puissiez voir exactement ce qui coince, dans quel fichier, et à quelle ligne précise.
Pour l’activer, ajoutez ces deux constantes dans wp-config.php :
1define( 'WP_DEBUG', true );2define( 'WP_DEBUG_DISPLAY', true );
L’erreur apparaît alors directement sur la page concernée, à l’endroit exact où le code fautif s’exécute.
Dans la pratique, la plupart des erreurs courantes proviennent de fichiers du cœur de WordPress ou d’extensions qui se chargent très tôt, elles apparaissent donc le plus souvent tout en haut de la page, parfois même avant l’affichage de votre en-tête.

Cette erreur s’affiche aussi bien dans votre tableau de bord que sur la partie publique de votre site, selon l’endroit où le code fautif se déclenche.

Pour conserver une trace de ces erreurs sans les afficher publiquement, ajoutez WP_DEBUG_LOG aux deux lignes déjà en place.
Un point technique important à connaître avant de l’activer, car seule, WordPress précise que cette constante ne fait rien tant que WP_DEBUG n’est pas également activée, ce qui est déjà le cas ici puisque vous l’avez réglée juste au dessus.
1define( 'WP_DEBUG_LOG', true );
Une fois cette ligne active, WordPress écrit chaque erreur dans un fichier debug.log, situé par défaut dans wp-content, au même niveau que les dossiers plugins et themes que vous connaissez déjà.
Ce fichier ne se crée qu’au moment où une erreur se produit réellement, pas à l’activation elle même.
À SAVOIR : cet emplacement par défaut n’est pas figé, WP_DEBUG_LOG accepte aussi un chemin personnalisé à la place de la simple valeur true, WordPress écrit alors le fichier à cet endroit précis plutôt que dans wp-content.

IMPORTANT : il me semble essentiel de souligner un point de sécurité avant de refermer cette section.
Ce fichier reste un simple fichier texte comme un autre, accessible publiquement si quelqu’un devine ou trouve son adresse exacte dans un navigateur, ce qui peut exposer des informations sur la structure de votre site à n’importe qui.
Ajoutez la règle ci-dessous dans votre fichier .htaccess, à la racine de votre site, pour en bloquer l’accès direct.
1<Files debug.log>2 Require all denied3</Files>
Une fois votre erreur identifiée et corrigée, désactivez WP_DEBUG et WP_DEBUG_DISPLAY, en les repassant à false. Le mode debug n’a sa place que le temps du diagnostic, jamais durablement sur un site en ligne.
Questions fréquentes sur le fichier wp-config.php
Sources :
GitHub, WordPress – fichier source officiel wp-config-sample.php
developer.wordpress.org – documentation officielle sur wp-config.php
fr.wordpress.org – modifier le fichier wp-config.php
o2switch – configuration des accès FTP
MySQL – jeu de caractères utf8mb3
MySQL – jeu de caractères utf8mb4
MySQL – jeux de caractères Unicode et interclassements
developer.wordpress.org – fonction wp_salt()
developer.wordpress.org – les nonces WordPress
developer.wordpress.org – le débogage sous WordPress
developer.wordpress.org – les permissions de fichiers
Apache – documentation officielle sur le contrôle d’accès
WordPress.org – forum, wp-config.php détecté comme malveillant
WordPress.org – générateur officiel de clés secrètes
GitHub, WordPress – fichier source setup-config.php
GitHub, WordPress – fichier source wp-load.php
GitHub, WordPress – fichier source install.php
GitHub, WordPress – fichier source repair.php
GitHub, WordPress – fichier source default-constants.php
WP Engine – résoudre les erreurs de mémoire allouée
WordPress.org – forum, avertissement PHP affiché en haut de page
Pour conclure sur le fichier wp-config.php
Si vous deviez retenir une seule chose de cet article, ce serait que wp-config.php n’est pas un fichier réservé aux spécialistes. C’est une suite de lignes de configuration, avec une logique claire une fois qu’on prend le temps de la comprendre. Il contient des informations essentielles, des réglages optionnels, et des règles de sécurité qui tiennent en une poignée de bonnes pratiques.
Ce qui impressionne au premier abord, ce n’est pas sa complexité, c’est son importance. Un fichier aussi court qui décide de tout, de la connexion à la base de données, à la sécurité de vos utilisateurs et la vitesse de votre site, c’est justement pour ça qu’il vaut la peine de le comprendre plutôt que de l’éviter.
Personne n’a besoin d’être développeur pour ouvrir ce fichier sans crainte. Ce qui fait la différence, c’est la méthode. Gardez toujours une copie de secours avant d’y toucher, vérifiez systématiquement votre site après chaque modification, et surtout, jamais de précipitation, ce fichier ne pardonne pas les fautes de frappe.
Vous savez maintenant localiser ce fichier, comprendre ses réglages essentiels, et reconnaître les erreurs les plus courantes qui lui sont liées. Cette compréhension ne remplace pas la prudence, un fichier aussi sensible reste un terrain où une simple erreur de frappe peut rendre votre site inaccessible.
L’objectif n’est pas de tout faire vous même, mais de comprendre de quoi il s’agit quand ce fichier pose problème, et de savoir reconnaître le moment où l’intervention d’un spécialiste devient la bonne décision.
C’est exactement l’esprit que je défends chez ÉvidenceWP, la liberté et l’indépendance de savoir ce qui se passe réellement sur son propre site, plutôt que d’en perdre complètement le contrôle.
Laisser un commentaire
Les articles qui pourraient vous intéresser.
Besoin d’être accompagné ?
Votre site WordPress mérite un partenaire de confiance, pas un prestataire de plus. Parlons de votre projet lors d’un appel découverte gratuit, sans engagement.








0 commentaires
Aucun commentaire pour le moment. Soyez le premier à réagir.