Le fichier .htaccess, c’est le panneau de contrôle caché de ton serveur Apache. Un simple fichier texte, sans nom avant le point, qui dicte à ton serveur comment se comporter avec ton site WordPress : redirections, mots de passe, en-têtes de sécurité. La vérité, c’est que 90 % des gens qui y touchent sur WordPress le font sans savoir ce qu’ils écrivent. Résultat : page blanche, erreur 500, site inaccessible. Ça n’arrive pas parce que le fichier est mystérieux, mais parce qu’une seule ligne mal écrite suffit à faire planter Apache.
À quoi sert vraiment un fichier .htaccess sur WordPress
WordPress génère automatiquement un fichier .htaccess dès que tu actives des permaliens « jolis ». Tu l’as peut-être déjà vu sans le savoir, planqué à la racine de ton installation, là où se trouve aussi le fichier wp-config.php. Ce fichier .htaccess gère par défaut le rewriting d’URL, donc tout le système de liens propres de ton site.
Mais son rôle va bien au-delà. Un fichier .htaccess peut rediriger des visiteurs vers d’autres pages, bloquer des adresses IP, forcer le HTTPS, protéger un dossier avec un mot de passe, ou encore ajouter des en-têtes de sécurité contre les attaques XSS et de force brute. C’est un couteau suisse, et c’est justement pour ça qu’il est dangereux si on le manipule à l’aveugle.
Détail crucial que beaucoup ignorent : le fichier .htaccess fonctionne uniquement sur des serveurs Apache ou LiteSpeed. Si ton hébergement tourne sous Nginx, ça ne marchera pas du tout. Tu devras passer par la configuration du serveur, ce qui n’est pas à la portée de tout le monde.
Créer un fichier .htaccess pour WordPress, étape par étape
Avant toute chose, vérifie que ton serveur autorise l’édition des fichiers .htaccess. Chez la grande majorité des hébergeurs, c’est activé par défaut. Mais certains serveurs désactivent cette option pour durcir la sécurité, et dans ce cas rien de ce qui suit ne fonctionnera.
La méthode la plus propre pour créer un fichier .htaccess WordPress :
- Connecte-toi à ton serveur via FTP (FileZilla fait très bien l’affaire) ou via le gestionnaire de fichiers de cPanel.
- Navigue jusqu’au dossier racine de ton site WordPress, celui qui contient wp-config.php.
- Crée un fichier texte sur ton ordinateur et nomme-le exactement .htaccess, sans oublier le point au début. Windows te compliquera la vie en ajoutant une extension .txt, donc active l’affichage des extensions de fichiers.
- Ouvre-le dans un éditeur de texte brut, pas Word. Notepad++, Sublime Text ou VS Code, peu importe, mais pas de traitement de texte qui insère du formatage invisible.
- Écris tes directives, une par ligne.
- Enregistre, puis téléverse le fichier dans le dossier racine de WordPress.
Petite subtilité : les permissions du fichier doivent être en 644. Une permission en 666 ou 777 ouvre une faille de sécurité béante que n’importe quel scanner détecte en quelques secondes.
Les directives .htaccess les plus utiles pour WordPress
Voici celles qui servent réellement, classées par usage. Ne les empile pas toutes d’un coup : ajoute une directive, teste, observe. C’est la seule façon de savoir laquelle casse ton site si quelque chose part en vrille.
- Forcer le HTTPS : une redirection 301 qui envoie tout le trafic HTTP vers HTTPS. Indispensable aujourd’hui, autant pour le SEO que pour la confiance des visiteurs.
- En-têtes de sécurité : X-Frame-Options, X-Content-Type-Options, Content-Security-Policy. Ces lignes protègent contre le clickjacking et le cross-site scripting.
- Protection par mot de passe : tu protèges un dossier entier avec une authentification basique. Utile pour un espace client ou une zone de test.
- Page de maintenance : tu rediriges temporairement tous les visiteurs vers une page d’attente pendant que tu bosses sur le site.
- Blocage d’IP : tu coupes l’accès à des adresses qui te spamment ou tentent de forcer l’admin.
- Limiter l’accès à wp-config.php et aux fichiers sensibles : une ligne, et tu fermes une porte d’entrée classique.
L’erreur qui transforme ton site en page blanche
Le fameux « Internal Server Error 500 » après une modification de .htaccess, tout le monde y passe. La cause est presque toujours la même : une ligne avec une faute de frappe, une directive mal orthographiée, ou une module Apache non chargé (mod_headers, mod_rewrite) sur ton hébergeur.
La règle d’or, sans exception : sauvegarde le fichier .htaccess avant chaque modification. Tu télécharges une copie sur ton ordinateur, et si ça casse, tu remets l’ancienne version par FTP en dix secondes. Sans cette sauvegarde, tu te retrouves à chercher l’erreur à l’aveugle dans le panneau de ton hébergeur.
Encore mieux : teste tes changements sur un environnement de préproduction. Un site de staging coûte trois fois rien chez la plupart des hébergeurs et t’évite de faire tomber ta production devant tes visiteurs.
Un fichier .htaccess qui fonctionne, c’est un fichier qu’on a testé ligne par ligne. Pas un copier-coller récupéré sur un forum.
.htaccess ou plugin de sécurité : il faut choisir
Beaucoup pensent qu’un fichier .htaccess remplace un plugin de sécurité. C’est faux, et c’est une erreur de raisonnement courante. Le .htaccess agit au niveau du serveur, avant même que WordPress ne charge une seule ligne de PHP. C’est un avantage énorme en performance, mais ça le rend limité : il ne connaît rien de ton contenu, de tes utilisateurs, ni de tes plugins.
Un plugin de sécurité, lui, analyse les requêtes dans WordPress, détecte les tentatives de connexion suspectes, scanne les fichiers modifiés. Les deux se complètent. La vraie bonne approche, c’est de mettre dans le .htaccess ce qui est statique et serveur (en-têtes, blocage IP, redirections) et de confier à un plugin ce qui demande de la logique applicative.
Et si ton hébergeur tourne sous Nginx, oublie complètement le .htaccess. Tu devras passer par les blocs de configuration serveur, soit via ton hébergeur, soit en éditant directement la config Nginx si tu as les droits. Dans ce cas, un bon plugin de sécurité devient ta seule option accessible.
Dernier point que personne ne dit assez fort : ne colle jamais un fichier .htaccess récupéré quelque part sans comprendre chaque ligne. Les directives héritées d’un vieux tutoriel de 2013 peuvent bloquer des fonctionnalités modernes, empêcher l’API REST de WordPress de répondre, ou casser l’éditeur de blocs. Un site qui fonctionne vaut mieux qu’un fichier .htaccess impressionnant.
