Vérificateur de syntaxe .htaccess

Collez le contenu d'un fichier .htaccess pour détecter instantanément les erreurs courantes : balises de bloc non fermées, noms de directives mal orthographiés, RewriteRule avec trop peu d'arguments et lignes RewriteCond sans règle associée.

Dernière mise à jour : 2026-09-20

Trouver les erreurs d'un fichier .htaccess

Un `.htaccess` est un fichier où un seul caractère fautif peut mettre à terre un site entier par une erreur 500. Collez-en le contenu et cet outil repère sur-le-champ les fautes typiques : une balise de bloc non refermée, un nom de directive mal orthographié, un `RewriteRule` à court d'arguments, un `RewriteCond` resté isolé.

**Ce qui est contrôlé ici, c'est la syntaxe, non le fait que le fichier fasse ce que vous vouliez.** Une règle de réécriture peut être parfaitement bien formée et pourtant ne mener personne à l'adresse que vous visiez, si les conditions viennent dans le mauvais ordre. Deux détails de la spécification méritent en outre d'être connus. Le premier : **un `RewriteCond` ne s'applique qu'au seul `RewriteRule` qui le suit immédiatement**, de sorte qu'énumérer plusieurs conditions et poser une unique règle à la fin ne fonctionne tout simplement pas. Le second : **si `AllowOverride` est désactivé dans la configuration du serveur, le `.htaccess` n'est jamais lu.** Lorsque rien ne se produit malgré ce que vous avez écrit, soupçonnez la configuration du serveur plutôt que le fichier.

Comment s'en servir

Collez le contenu de votre .htaccess Entrez le fichier entier tel quel.
Essayez d'abord les exemples Un exemple valide et un exemple fautif sont fournis.
Lisez les lignes signalées **Les balises non refermées et les arguments manquants sont rapportés avec leur numéro de ligne.**
Vérifiez la configuration du serveur si rien n'agit **Si `AllowOverride` est désactivé, le fichier n'est pas lu.**

Astuces pour en tirer le meilleur parti

Ce vérificateur est une analyse statique heuristique, ligne par ligne — ce n'est pas un véritable analyseur Apache. Testez toujours sur un serveur réel ou un environnement de staging avant la mise en production.
Si vous avez accès au terminal du serveur Apache, apachectl configtest reste la vérification de syntaxe la plus fiable qui soit. Cet outil convient pour des contrôles rapides quand cette commande n'est pas accessible, par exemple en hébergement mutualisé.
L'avertissement « directive non reconnue » n'est qu'une hypothèse peu fiable fondée sur une liste fixe. Si vous utilisez une directive d'un module moins courant, cet avertissement ne signifie pas forcément une erreur.
Empiler plusieurs lignes RewriteCond à la suite est un usage normal (elles agissent comme des conditions ET). Cet outil n'avertit que lorsque la dernière RewriteCond d'une chaîne n'est pas suivie d'une RewriteRule.
Avant de déployer en production, appliquez les changements par petites étapes et vérifiez chacune d'elles, plutôt que de remplacer tout le fichier d'un coup.

Dans quels cas s'en servir

Pour vérifier avant la mise en ligne

**Une erreur dans le `.htaccess` abat le site entier, ce qui rend la vérification préalable largement payante.**

Pour compléter un jeu de règles de réécriture

Après avoir ajouté une condition à des règles existantes, vous voyez si la forme a tenu.

Pour déchiffrer une configuration héritée

Dans un fichier longuement complété, vous établissez si certaines parties ont cessé d'agir.

Pour cerner une erreur 500

**Vous établissez d'abord si c'est la syntaxe qui empêche le serveur de démarrer.**

Vocabulaire du .htaccess

RewriteEngine: La directive qui active la réécriture. **À moins de la poser à `On`, aucune des règles suivantes n'agit.**
RewriteCond: Une condition portant sur une réécriture. **Elle ne s'applique qu'au seul `RewriteRule` qui la suit immédiatement**, ce qu'il convient de garder à l'esprit.
RewriteRule: La règle de réécriture elle-même, qui prend un motif, un remplacement et des drapeaux tels que `[L,QSA]`.
Drapeaux: Les réglages entre crochets après une règle. `L` arrête ici le traitement et `QSA` reporte la chaîne de requête.
Balise de bloc: Un encadrement tel que `` ou ``. **En laisser un non refermé produit une erreur 500.**
AllowOverride: Le réglage côté serveur qui décide des directives qu'un `.htaccess` peut employer. **Là où il est désactivé, le fichier n'est pas lu.**

Questions fréquentes

La cause la plus fréquente est que la configuration principale d'Apache a AllowOverride None pour ce répertoire, ce qui fait que .htaccess est totalement ignoré. Demandez à l'administrateur du serveur de confirmer que AllowOverride All (ou au moins les catégories dont vous avez besoin, comme AuthConfig ou FileInfo) est activé. Vérifiez également qu'un cache navigateur ou CDN ne sert pas une ancienne version.

La forme de base est RewriteRule motif substitution [drapeaux]. Le motif est une expression régulière comparée au chemin d'URL demandé (sans la barre oblique initiale), et la substitution peut référencer les groupes capturés du motif via $1, $2, etc. Les drapeaux se placent entre crochets, séparés par des virgules, comme [L] (arrêter le traitement des règles suivantes) ou [R=301] (redirection permanente).

Une cause très fréquente est que l'URL réécrite correspond de nouveau au motif de la même RewriteRule, si bien qu'Apache la réécrit sans cesse. La solution habituelle consiste à ajouter un RewriteCond tel que %{REQUEST_FILENAME} !-f (n'appliquer la règle que si le chemin ne correspond pas encore à un fichier existant), afin que la règle cesse de s'appliquer une fois la cible réellement présente.

Sur la plupart des hébergements mutualisés, toutes les pages de ce répertoire se mettent à renvoyer une erreur « 500 Internal Server Error ». Si vous avez accès au journal d'erreurs du serveur, c'est le moyen le plus rapide de repérer la ligne et la cause exactes.

Non, cela ne peut pas être garanti. Cet outil effectue une vérification statique heuristique, ligne par ligne, et ne reproduit pas fidèlement le comportement du véritable analyseur Apache. Le chargement du module requis (comme mod_rewrite) ou l'autorisation d'une directive dans ce contexte dépendent de l'environnement serveur — vérifiez toujours sur un environnement de staging ou le serveur réel avant de vous fier au résultat.

Anecdote — Pourquoi ce nom « .htaccess » ?

Le nom « .htaccess » est l'abréviation de « hypertext access » (accès à l'hypertexte), et son histoire remonte aux premières versions de NCSA httpd puis d'Apache, vers 1995. Il fut introduit à l'origine pour permettre aux propriétaires d'un répertoire de configurer une protection par mot de passe (authentification Basic) sur leur propre espace, sans avoir à toucher au fichier de configuration global du serveur (httpd.conf), que seul l'administrateur pouvait modifier.

Ce qui rend .htaccess si pratique, c'est que dès lors que l'administrateur Apache l'a autorisé via la directive AllowOverride, les changements prennent effet dès le téléversement du fichier par FTP ou un gestionnaire de fichiers, sans redémarrage du serveur. Cela permet aux utilisateurs d'un hébergement mutualisé, qui n'ont généralement pas accès à la configuration principale, de gérer redirections, mise en cache et restrictions d'accès répertoire par répertoire.

Cette commodité a toutefois un coût. La documentation officielle d'Apache recommande explicitement de placer les directives dans la configuration principale du serveur plutôt que dans .htaccess dès lors qu'on y a accès. La raison est simple : à chaque requête, Apache doit rechercher et relire les fichiers .htaccess dans chaque répertoire parent, ce qui entraîne une surcharge de performance non négligeable par rapport à une configuration centralisée.

Une simple erreur de syntaxe peut aussi coûter cher : sur de nombreux hébergements mutualisés, un .htaccess invalide transforme toutes les pages de ce répertoire en une page blanche « 500 Internal Server Error », et retrouver la cause exacte peut prendre un temps considérable. Faire passer un contrôle statique rapide comme celui-ci, en plus d'une relecture attentive, aide à repérer les étourderies avant qu'elles ne provoquent une panne après la mise en ligne.

Voir toutes les anecdotes