• Site WordPress

Fichier wp-config.php : le guide complet

Avatar de Kévin Raux, Webmaster et consultant SEO sur fond blanc.

Article publié par Kévin

Créé le 13 août 2026

Dernière mise à jour le 17 août 2026

Temps de lecture estimé : 51 minutes

É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

  • wp-config.php est le fichier de configuration central de WordPress, il stocke les identifiants de connexion à la base de données, les clés de sécurité, et plusieurs réglages qui déterminent le comportement de votre site. Il se charge à chaque page vue, et certains de ses réglages, comme l’adresse du site, priment sur les valeurs enregistrées dans la base de données sans jamais les modifier. WordPress ne l’écrase jamais lors d’une mise à jour, il reste même le seul endroit prévu pour accueillir vos propres réglages personnalisés.
  • WordPress ne distribue jamais ce fichier directement dans ses archives, mais seulement un modèle vide nommé wp-config-sample.php. Dans la grande majorité des installations, vous ne le voyez jamais, l’assistant d’installation de votre hébergeur crée wp-config.php à votre place. Ce modèle sert pour une installation manuelle sans assistant, ou pour récupérer un fichier disparu.
  • Au delà de ce que contient ce fichier par défaut, il peut aussi accueillir bien d’autres constantes optionnelles, réparties en huit thèmes, mémoire allouée, organisation des dossiers, gestion du contenu et de la base, environnement, sécurité et administration, mises à jour, réseau de sites, et tâches planifiées.
  • Ce fichier se trouve à la racine de votre installation, dans le dossier technique que WordPress désigne par ABSPATH, accessible via le gestionnaire de fichiers de votre hébergeur ou un client FTP comme FileZilla ou Cyberduck.
  • Il contient notamment les identifiants de base de données, avec le bon jeu de caractères à utiliser, utf8mb4 plutôt que utf8, les huit clés et sels de sécurité, le préfixe des tables, l’adresse du site avec WP_SITEURL et WP_HOME, et le mode debug, chaque nouvelle constante devant respecter une syntaxe précise pour fonctionner correctement.
  • Pour le modifier sans risque, toujours conserver une copie intacte avant toute intervention, et utiliser un éditeur de texte adapté au code, jamais un logiciel de traitement de texte.
  • Le sécuriser passe par trois leviers principaux, restreindre ses permissions à 440 ou 400, bloquer son accès direct via .htaccess ou Nginx, et savoir reconnaître les signes d’un fichier compromis, comme du code encodé ou une date de modification suspecte. Le déplacer hors de la racine du site reste un choix débattu, sans réel gain de sécurité une fois le serveur compromis.
  • Pour générer ou régénérer ce fichier, deux méthodes fiables existent selon votre situation, l’outil d’installation automatique de votre hébergeur pour un nouveau site, ou la copie manuelle de wp-config-sample.php, la solution la plus rapide en cas de fichier disparu ou corrompu, deux symptômes bien distincts à savoir reconnaître, l’assistant d’installation qui réapparaît dans un cas, un écran blanc dans l’autre.
  • Les erreurs les plus courantes liées à ce fichier sont l’erreur de connexion à la base de données, le message de mémoire allouée dépassée, et les erreurs PHP identifiables grâce au mode debug.

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 :

  • Les réglages de la base de données : cet espace de stockage séparé de vos fichiers conserve le texte de vos articles et de vos pages, vos réglages, vos commentaires et vos comptes utilisateurs. Ce bloc contient son nom, l’identifiant et le mot de passe pour y accéder, et l’adresse du serveur qui l’héberge.
  • Les clés et sels de sécurité : ces huit chaînes de caractères aléatoires protègent vos cookies de connexion et vos formulaires contre la falsification.
  • Le préfixe des tables : ce texte placé devant le nom de chaque table organise votre base de données, wp_ par défaut.
  • La constante ABSPATH : ce mécanisme indique à WordPress l’emplacement de ses propres fichiers, et déclenche le démarrage du logiciel.
  • Accueillir des réglages supplémentaires : le fichier porte lui même un repère, le commentaire That’s all, stop editing! Happy publishing., et invite à ajouter toute valeur personnalisée avant cette ligne. Vous en verrez plusieurs exemples plus loin dans l’article.

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 :

  • Il est chargé à chaque page vue qui n’est pas servie depuis le cache, ce dispositif qui sert une copie déjà préparée de la page pour aller plus vite.
  • Un réglage précis peut y prendre le pas sur la base de données. C’est le cas de l’adresse du site, WordPress précise qu’une valeur posée dans le fichier prend le pas sur celle enregistrée dans la base de données, sans la modifier.
  • Il résiste aux mises à jour. WordPress ne distribue jamais de wp-config.php dans ses archives, seulement un modèle nommé wp-config-sample.php, et mettre à jour le CMS laisse votre fichier intact.

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 :

  • Le gestionnaire de fichiers de votre hébergeur, accessible depuis votre espace cPanel ou équivalent. C’est la méthode la plus simple, elle ne demande aucun logiciel supplémentaire.
  • Un client FTP installé sur votre ordinateur, comme FileZilla ou Cyberduck, connecté avec les identifiants fournis par votre hébergeur (adresse du serveur, identifiant et mot de passe).
Le fichier wp-config.php visible à la racine du site dans le gestionnaire de fichiers de l'hébergeur, entouré des dossiers wp-admin, wp-content et wp-includes, ainsi que du fichier wp-settings.php.
Le fichier wp-config.php se trouve à la racine du site, ici vu depuis le gestionnaire de fichiers du cPanel, aux côtés des dossiers wp-admin, wp-content et wp-includes.

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

Le fichier wp-config.php visible à la racine du site depuis un client FTP, entouré des dossiers wp-admin, wp-content et wp-includes, ainsi que du fichier wp-settings.php.
La même racine du site, vue cette fois depuis un client FTP plutôt que depuis le gestionnaire de fichiers de l’hébergeur.

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.

  • DB_NAME, le nom de la base de données.
  • DB_USER, l’identifiant utilisé pour y accéder.
  • DB_PASSWORD, le mot de passe associé à cet identifiant.
  • DB_HOST, l’adresse du serveur qui héberge la base, localhost la plupart du temps chez un hébergeur mutualisé.

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.

  • Le jeu de caractères DB_CHARSET : il définit quels caractères votre base de données peut stocker.

    La valeur utf8 dans MySQL est en réalité limitée à trois octets par caractère, elle gère bien les lettres accentuées mais pas les emojis ni certains caractères rares.

    La valeur utf8mb4 va jusqu’à quatre octets par caractère, ce qui couvre l’intégralité de la norme Unicode, emojis compris.

    C’est la valeur que WordPress utilise par défaut aujourd’hui à l’installation.

    Concrètement, un site en utf8 qui reçoit un commentaire avec un emoji peut afficher un caractère cassé, voire déclencher une erreur d’enregistrement en base.
  • L’interclassement DB_COLLATE : il définit comment la base compare et trie les caractères entre eux, par exemple pour classer des résultats par ordre alphabétique.

    Le suffixe _ci veut dire insensible à la casse, pour que les majuscules et minuscules soient traitées pareil.

    Le suffixe _general compare rapidement mais de façon simplifiée, tandis que _unicode est plus précis linguistiquement, légèrement plus lent.

    Je vous recommande de laisser cette valeur vide, WordPress l’assigne alors automatiquement selon le jeu de caractères choisi.

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.

  • wp-admin, qui renferme les fichiers de votre tableau de bord, l’interface où vous gérez votre site au quotidien.
  • wp-includes, qui renferme le moteur de WordPress, les fichiers qui le font fonctionner en coulisses.
  • wp-content, qui renferme vos thèmes, vos extensions et vos médias, tout ce que vous personnalisez concrètement.

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 :

  • WP_SITEURL définit l’adresse où se trouvent les fichiers cœur de WordPress.
  • WP_HOME définit l’adresse que vos visiteurs utilisent pour accéder au 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

WP_MEMORY_LIMIT

Augmenter la mémoire allouée à WordPress, utile en cas d’erreur de mémoire épuisée.

WP_MAX_MEMORY_LIMIT

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

WP_CONTENT_DIR / WP_CONTENT_URL

Déplacer le dossier wp-content.

WP_PLUGIN_DIR / WP_PLUGIN_URL

Déplacer le dossier des extensions.

UPLOADS

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

WP_POST_REVISIONS

Limiter ou désactiver les révisions d’articles.

AUTOSAVE_INTERVAL

Espacer les enregistrements automatiques.

EMPTY_TRASH_DAYS

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

WP_ENVIRONMENT_TYPE

Déclarer le site comme local, développement, préproduction ou production.

WP_CACHE

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

DISALLOW_FILE_EDIT

Désactiver l’éditeur de thème et d’extensions dans le tableau de bord.

DISALLOW_FILE_MODS

Bloquer aussi l’installation et la mise à jour depuis le tableau de bord.

FORCE_SSL_ADMIN

Forcer le HTTPS sur l’administration.

WP_HTTP_BLOCK_EXTERNAL / WP_ACCESSIBLE_HOSTS

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

AUTOMATIC_UPDATER_DISABLED

Désactiver toutes les mises à jour automatiques.

WP_AUTO_UPDATE_CORE

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

WP_ALLOW_MULTISITE

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

DISABLE_WP_CRON / ALTERNATE_WP_CRON

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 :

Syntaxe

1define( 'NOM_DE_LA_CONSTANTE', valeur );
  • define, l’instruction qui crée la constante.
  • Le nom de la constante, toujours entre guillemets simples droits et toujours en majuscules, exactement comme indiqué dans le tableau. La moindre faute de frappe empêche WordPress de la reconnaître.
  • La valeur, dont la forme change selon ce qu’elle représente.
  • Le point-virgule final, obligatoire, sans lui WordPress ne peut pas lire la ligne.

La valeur prend ensuite l’une de ces trois formes :

  • Un interrupteur vrai ou faux, sans guillemets. Exemple : define( 'WP_CACHE', true );.
  • Un texte, toujours entre guillemets simples droits. Exemple, define( 'WP_ENVIRONMENT_TYPE', 'staging' );.
  • Un nombre, sans guillemets s’il s’agit d’un chiffre pur, avec guillemets s’il inclut une lettre comme pour une taille de mémoire. Exemple, define( 'WP_MEMORY_LIMIT', '256M' );.

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.

wp-config.php

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 :

  • Récupérez d’abord une copie du fichier tel qu’il est actuellement, sans rien modifier.

    Peu importe la méthode, le gestionnaire de fichiers de votre hébergeur ou un client FTP fonctionnent aussi bien l’un que l’autre.

    Sur la capture ci-dessous, je le récupère via le gestionnaire de fichiers de mon cPanel, mais la plupart des hébergeurs mutualisés proposent un gestionnaire de fichiers, avec ou sans cPanel.
Menu contextuel du gestionnaire de fichiers avec l'option "Download" en surbrillance pour télécharger le fichier wp-config.php.
Faites un clic droit sur le fichier wp-config.php puis choisissez « Download » pour en récupérer une copie.
  • Gardez cette copie intacte de côté, sans y toucher. C’est votre filet de sécurité, celui qui vous permet de tout remettre en état en quelques secondes si quelque chose tourne mal.
  • Travaillez ensuite sur un second exemplaire, une copie de la copie, avec un éditeur de texte adapté au code, comme Visual Studio Code. WordPress déconseille explicitement les logiciels de traitement de texte comme Word pour modifier ses fichiers.
Le fichier wp-config.php ouvert dans un éditeur de code, ici Visual Studio Code.
Une fois téléchargée, ouvrez la copie du fichier avec un éditeur de code comme Visual Studio Code, jamais avec un logiciel de traitement de texte.
  • Faites vos modifications sur cette copie de travail, tranquillement, sans pression.
  • Une fois satisfait, remplacez l’ancien fichier en ligne par votre nouvelle version.
  • Testez votre site immédiatement après, la page d’accueil d’abord, puis la connexion à votre tableau de bord. Si les deux fonctionnent normalement, c’est terminé. Si un problème apparaît, remettez en ligne la copie intacte que vous avez conservée à la première étape, le temps de comprendre ce qui a coincé.

IMPORTANT : voici deux conseils afin de diminuer les risques lorsque vous interviendrez sur le fichier wp-config.php.

  • le gestionnaire de fichiers de la plupart des hébergeurs propose aussi une option « Edit » qui permet de modifier le fichier directement dans le navigateur, sans le télécharger.

    Je préfère volontairement l’éviter pour ce fichier précis, elle ne garantit aucune copie de secours automatique, contrairement à la méthode du téléchargement, qui vous laisse toujours une version intacte sur votre ordinateur avant même de commencer.
  • Autre chose à laquelle je tiens, distincte de la simple copie du fichier. Une sauvegarde complète de votre site, fichiers et base de données comprises, reste un filet de sécurité supplémentaire que je recommande avant toute intervention technique, même une modification qui semble aussi simple que celle-ci.

    Elle vous protège non pas contre une erreur dans ce fichier précis, mais contre un problème qui surviendrait ailleurs pendant que vous manipulez les fichiers de votre site, car même en faisant attention, il peut arriver de faire une erreur sans s’en rendre compte, autant donc le prévoir plutôt que de le subir.

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.

Menu contextuel du gestionnaire de fichiers avec l'option "Change Permissions" en surbrillance.
Faites un clic droit sur le fichier wp-config.php puis choisissez « Change Permissions ».

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 ».

Fenêtre de modification des permissions avec des cases à cocher pour Lecture, Écriture et Exécuter selon trois colonnes, Utilisateur, Groupe et Tout le monde.
La fenêtre affiche la valeur numérique de chaque colonne en direct à mesure que vous cochez ou décochez les cases.

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.

.htaccess

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.

Nginx

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 :

  • Une date de modification qui ne correspond à aucune intervention de votre part. Vous avez déjà vu, plus haut dans cet article, la colonne « Last Modified » du gestionnaire de fichiers. Si cette date change alors que vous n’avez touché à rien, c’est un signal à prendre au sérieux.
  • La présence de fonctions PHP que vous n’avez jamais ajoutées vous même, en particulier eval, base64_decode, ou gzinflate, souvent combinées entre elles pour dissimuler du code exécutable sous une longue chaîne de caractères illisible.

Voici, à titre d’exemple illustratif uniquement, à quoi ce genre d’ajout peut ressembler dans le fichier.

Exemple illustratif

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.

  • Depuis votre cPanel, repérez la section « Scripts », puis cliquez sur l’icône « WordPress ».
Section "Scripts" du cPanel avec l'icône WordPress mise en évidence pour accéder à Softaculous.
Depuis la section « Scripts » de votre cPanel, cliquez sur l’icône « WordPress » pour accéder à Softaculous.
  • Vous arrivez sur un écran de présentation. Cliquez sur « Installer », puis sur « Installation » dans le menu qui s’ouvre.
Écran de présentation de WordPress dans Softaculous avec le menu "Installer" ouvert et l'option "Installation" en surbrillance.
Cliquez sur « Installer » puis sur « Installation » pour lancer l’assistant.
  • En bas de cet écran, vous retrouvez aussi la liste de tous les sites WordPress déjà installés sur votre hébergement.

En copiant manuellement wp-config-sample.php

Ce scénario se présente généralement à vous dans deux cas de figure :

  • Vous installez WordPress manuellement, sans passer par l’assistant automatique, et vous préférez préparer ce fichier vous même dès le départ.
  • L’assistant automatique a tenté de le créer à votre place mais n’a pas pu écrire dans le dossier d’installation.

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 :

  • wp-config-sample.php est un modèle. WordPress ne peut pas connaître à l’avance le nom de votre base de données, votre identifiant ou votre mot de passe, ces informations sont propres à chaque hébergement et changent d’un site à l’autre.

    Plutôt que de livrer un fichier déjà rempli avec de fausses valeurs qu’il faudrait de toute façon corriger, WordPress fournit ce modèle vide, à copier puis à compléter vous même, et franchement c’est vraiment pratique et bien pensé.

    Ce fichier se trouve exactement au même endroit que wp-config.php, à la racine de votre installation, juste à côté de lui.

    À titre d’exemple, voici à quoi ressemble cet emplacement sur un site où l’installation a déjà réussi, wp-config-sample.php reste présent aux côtés de wp-config.php, WordPress ne le supprime jamais après l’avoir utilisé.
Liste des fichiers à la racine de l'installation WordPress avec wp-config-sample.php et wp-config.php entourés côte à côte.
Le fichier wp-config-sample.php se trouve au même endroit que wp-config.php, à la racine de votre installation.
  • Pour l’utiliser, faites un clic droit dessus puis choisissez « Rename », et donnez lui le nom wp-config.php. Avant de renommer, vérifiez qu’aucun fichier wp-config.php n’existe déjà à cet endroit, le renommage entrerait sinon en conflit avec lui ou l’écraserait.
Menu contextuel du gestionnaire de fichiers avec l'option "Rename" en surbrillance sur le fichier wp-config-sample.php.
Faites un clic droit sur wp-config-sample.php puis choisissez « Rename » pour le transformer en wp-config.php.
  • Une fois renommé, ouvrez le fichier pour le compléter, directement avec l’option « Edit » du gestionnaire de fichiers, ou en le téléchargeant sur votre ordinateur pour l’ouvrir avec un éditeur de code, jamais avec un logiciel de traitement de texte.

    Remplissez les informations de connexion à votre base de données que votre hébergeur vous a fournies, DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Générez ensuite vos clés et sels de sécurité avec l’outil officiel de WordPress, déjà utilisé plus haut dans cet article, et collez les à la place des huit lignes existantes.

Voici à quoi ressemble ce fichier modèle dans son intégralité, tel qu’il est distribué par WordPress aujourd’hui :

wp-config-sample.php

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.

  • Situation N°1 · Le fichier a disparu : le code source de WordPress prévoit précisément ce cas, si wp-config.php est introuvable, votre site ne plante pas et n’affiche pas d’erreur, il redirige automatiquement vers l’assistant d’installation de WordPress.

    Concrètement, à la place de votre site, vous verrez apparaître un écran de sélection de langue, exactement comme lors d’une toute première installation, ce qui peut être déstabilisant si on ne sait pas pourquoi.
Écran de sélection de la langue de l'assistant d'installation de WordPress, qui apparaît automatiquement quand le fichier wp-config.php est introuvable.
Si wp-config.php a disparu, WordPress affiche cet écran d’installation à la place de votre site.
  • Situation N°2 · Le fichier est corrompu : une erreur de syntaxe dans un fichier qui existe toujours produit un symptôme complètement différent, un écran blanc ou une erreur fatale, jamais l’assistant d’installation.

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.

  • Récupérez une copie propre de wp-config-sample.php, soit directement sur GitHub à l’adresse déjà donnée plus haut, soit depuis les fichiers de votre propre installation s’il est toujours présent à côté du fichier disparu ou corrompu.
  • Avant de renommer cette copie en wp-config.php, vérifiez qu’aucun fichier ne porte déjà ce nom à cet endroit. Si le fichier corrompu est encore présent, supprimez le ou renommez le temporairement pour éviter tout conflit.
  • Remplissez les informations de connexion à votre base de données. Contrairement à une toute nouvelle installation, ces informations existent déjà et fonctionnaient jusque là, elles sont normalement disponibles dans l’espace d’administration de votre hébergeur, ou peuvent vous être redonnées sur simple demande à leur support.
  • Générez de nouvelles clés et sels de sécurité avec l’outil officiel de WordPress, et collez-les à la place des huit lignes existantes.
  • Envoyez ce fichier complété à la racine de votre site, à l’endroit exact où se trouvait l’ancien.
  • Testez votre site immédiatement, la page d’accueil d’abord, puis la connexion à votre tableau de bord.

À 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

Message d'erreur WordPress "Error establishing a database connection" affiché à la place du site
C’est souvent la première chose que voit un visiteur quand WordPress ne parvient plus à joindre sa 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 :

  • Relisez attentivement DB_NAME, DB_USER et DB_PASSWORD, une seule lettre de travers suffit à provoquer cette erreur.
  • Vérifiez DB_HOST. Cette valeur n’est pas universelle, elle change selon votre hébergeur. La documentation officielle de WordPress recense d’ailleurs les valeurs à utiliser chez plusieurs dizaines d’hébergeurs, localhost reste la plus répandue chez les hébergeurs mutualisés comme o2switch, mais ce n’est pas systématique partout.
  • Si vous avez changé le mot de passe de votre base de données récemment, directement depuis l’espace d’administration de votre hébergeur, pensez à le mettre aussi à jour dans wp-config.php. Ce fichier ne se synchronise jamais automatiquement avec votre hébergeur, une mise à jour d’un côté sans l’autre suffit à provoquer cette erreur.

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.

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.

Message de WordPress invitant à ajouter la constante WP_ALLOW_REPAIR dans wp-config.php pour activer la réparation automatique de la base de données.
Sans cette constante, WordPress affiche ce message plutôt que l’outil de réparation lui même.

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.

Écran de réparation automatique de WordPress avec les boutons "Réparer la base de données" et "Réparer et optimiser la base de données".
Une fois WP_ALLOW_REPAIR ajoutée, WordPress propose de réparer automatiquement les problèmes courants de base de données.

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.

  • Depuis la section « Logiciel » de votre cPanel, cliquez sur « Sélectionner une version de PHP ».
Section "Logiciel" du cPanel avec l'option "Sélectionner une version de PHP" mise en évidence.
Depuis la section « Logiciel » de votre cPanel, cliquez sur « Sélectionner une version de PHP ».
  • Cliquez sur l’onglet « Options ».
Interface PHP Selector avec l'onglet "Options" mis en évidence à côté de l'onglet "Extensions".
Cliquez sur l’onglet « Options » pour accéder aux réglages de mémoire.
  • Choisissez la valeur souhaitée dans le menu déroulant « memory_limit ».
Réglage memory_limit du PHP Selector avec un sélecteur de valeur affichant 128M.
Choisissez la limite de mémoire PHP souhaitée dans le menu déroulant « memory_limit ».

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.

wp-config.php

1define( 'WP_MEMORY_LIMIT', '256M' );
Fichier wp-config.php avec la constante WP_MEMORY_LIMIT ajoutée à la valeur 256M.
Vous pouvez aussi augmenter cette limite directement dans wp-config.php, avec la constante WP_MEMORY_LIMIT.

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 :

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.

Message d'avertissement PHP affiché en haut du tableau de bord de WordPress après activation de WP_DEBUG_DISPLAY.
Une fois WP_DEBUG_DISPLAY activée, une erreur PHP s’affiche directement dans le tableau de bord si elle s’y produit.

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.

Message d'avertissement PHP affiché en haut de la partie publique d'un site WordPress après activation de WP_DEBUG_DISPLAY.
La même erreur s’affiche aussi sur la partie visible par vos visiteurs si elle s’y produit.

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.

wp-config.php

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.

Fichier debug.log localisé dans le dossier wp-content, avec un aperçu d'une ligne d'erreur enregistrée, chemin d'accès masqué.
Le fichier debug.log se trouve dans wp-content et enregistre chaque erreur avec sa date et son emplacement exact dans le code.

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.

.htaccess

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

wp-config-sample.php est le modèle vide fourni par WordPress, sans aucune information personnelle.

wp-config.php est la version réellement utilisée par votre site, complétée avec vos propres identifiants de connexion à la base de données et vos clés de sécurité.

Le premier reste présent en permanence sur votre installation, le second est celui que WordPress charge à chaque page vue.

Non, sa taille n’a aucun impact mesurable sur les performances.

Même avec plusieurs dizaines de lignes, ce fichier reste minuscule à lire pour PHP comparé au reste du chargement d’une page.

Si votre site est lent, la cause se trouve ailleurs, absence de mise en cache, images trop lourdes, ou hébergement sous dimensionné.

Non, jamais volontairement. Comme vu plus haut dans cet article, sa disparition redirige automatiquement votre site vers l’assistant d’installation de WordPress, à la place de votre contenu habituel.

Votre base de données reste intacte, mais votre site devient inaccessible pour vos visiteurs tant que le fichier n’est pas remis en place.

En général non, PHP relit ce fichier à chaque nouvelle requête, votre modification s’applique donc immédiatement.

Si le changement ne semble pas pris en compte, videz tout de même le cache de votre extension de performance, comme WP Rocket, qui peut continuer à servir une version enregistrée de vos pages le temps que vous rechargiez.

Non, jamais. Les identifiants de connexion à la base de données et les clés de sécurité sont propres à chaque installation, ils ne doivent jamais être copiés d’un site à un autre.

Seule la structure générale du fichier, elle, reste la même partout, puisqu’elle provient du même modèle wp-config-sample.php.

Ce fichier est rarement le point d’entrée direct d’un piratage, la faille exploitée se trouve le plus souvent ailleurs, une extension ou un thème mal sécurisé, ou des identifiants FTP ou SSH dérobés.

Une fois qu’un site est compromis, en revanche, wp-config.php devient une cible fréquente pour y dissimuler du code malveillant, puisqu’il concentre vos informations les plus sensibles.

C’est justement pour ça que les mesures vues plus haut dans cet article, permissions, blocage serveur, détection d’un fichier compromis, méritent d’être appliquées plutôt qu’ignorées.

Non, il n’a pas besoin d’un traitement à part. Il doit simplement faire partie de votre sauvegarde complète habituelle, au même titre que vos autres fichiers et votre base de données.

Je détaille l’ensemble de la méthode, extensions recommandées, fréquence adaptée à votre activité, et bonnes pratiques de stockage, dans mon guide dédié pour sauvegarder un site WordPress.

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.

0 commentaires

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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

En remplissant et en soumettant ce formulaire, vous consentez à ce que ÉvidenceWP traite les données recueillies pour répondre à votre commentaire. Pour en savoir plus sur la gestion de vos données personnelles et pour exercer vos droits, reportez-vous à la présente politique de confidentialité.

Vous serez averti·e par e-mail dès que l'équipe ÉvidenceWP ou une autre personne aura répondu à votre 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.