Erreur 403 Forbidden : comment lire la cause réelle et rétablir l’accès au site

L’erreur 403 Forbidden fait partie de ces messages que tout le monde a déjà vus et que presque personne ne sait lire. Le serveur répond, il répond vite, et il refuse. Il n’est donc pas évident de savoir s’il faut vider un cache, corriger une permission, réveiller un hébergeur, changer de navigateur ou désactiver un pare-feu.

Ce guide part d’une question que la plupart des pages concurrentes contournent : qui, exactement, se fait refuser l’accès ? Un visiteur isolé ? Tous les visiteurs d’un même pays ? Un robot d’exploration ? Un jeton d’API ? Un utilisateur connecté avec le mauvais rôle ? La réponse change tout, parce que la cause et le correctif n’ont strictement rien à voir d’un cas à l’autre.

Une erreur 403 Forbidden signifie que le serveur a compris la requête et qu’il refuse de la traiter. La ressource peut exister, être parfaitement servie à d’autres, et rester inaccessible à vous. C’est un refus d’autorisation, pas une page manquante. Cette nuance explique pourquoi la moitié des réponses trouvées en ligne (« videz votre cache ») ne résolvent rien, et pourquoi l’autre moitié (« passez tout en 777 ») crée des failles de sécurité.

Nous avons traité cette erreur côté visiteur, côté éditeur WordPress, côté CDN et côté hébergement mutualisé. Ce qui revient le plus souvent n’est pas une panne : c’est une règle oubliée, une permission héritée d’une migration, ou un pare-feu applicatif qui bloque plus large que prévu.

Dans ce guide : un tableau de diagnostic symptôme → cause probable → solution, une comparaison nette entre 401, 403 et 404, huit causes réelles classées par fréquence, 14 solutions détaillées et classées par efficacité, les cas WordPress et Google Search Console, cinq retours du terrain, notre verdict éditorial et une FAQ directement exploitable.

En bref

• Ce que c’est : un refus d’autorisation. Le serveur a compris la requête et décide de ne pas la servir. La ressource existe souvent.
• La première question : l’erreur touche-t-elle tout le monde ou seulement vous ? Cette seule réponse élimine la moitié des pistes.
• Le réflexe utile : ouvrir les logs serveur et lire le motif du refus. Sans cette preuve, on corrige au hasard.
• Les deux causes dominantes : une règle d’accès (.htaccess, Nginx, WAF) et des permissions ou une propriété de fichiers incorrectes.
• Le piège à éviter : passer les fichiers en 777 ou désactiver définitivement le WAF. On échange une erreur visible contre une faille invisible.
• Côté SEO : une 403 sur une page publique ou sur une ressource bloque son exploration. Une 403 sur une zone privée est normale.
• Côté éditeur : un refus mal ciblé est une dette technique. Un refus bien ciblé est une mesure de sécurité.

Diagnostic express : le tableau symptôme → cause probable → solution à essayer

Avant d’entrer dans le détail, situez votre cas. Cette grille couvre la quasi-totalité des situations que nous avons rencontrées en support, en audit et en test.

Ce tableau fonctionne comme un arbre de décision en une passe. Si votre cas n’y figure pas, la section Diagnostic rapide plus bas affine la lecture, et les 14 méthodes donnent la marche à suivre complète.

Qu’est-ce qu’une erreur 403 Forbidden ?

Une erreur 403 Forbidden est un code de statut HTTP qui indique que le serveur a reçu la requête, l’a comprise, et refuse néanmoins d’y répondre. La ressource peut exister. Le serveur sait qu’elle existe. Il choisit de ne pas la servir.

C’est une différence de nature, pas de degré. Un serveur en panne renvoie une erreur 5xx. Une ressource absente renvoie une 404. Une requête refusée faute d’autorisation renvoie une 403. Trois familles, trois diagnostics, trois séries de correctifs.

Ce que dit exactement la norme HTTP

La spécification HTTP Semantics, la RFC 9110, définit le 403 à la section 15.5.4. Elle précise trois points que l’on oublie trop souvent :

• le serveur a compris la requête mais refuse de l’exécuter ;
• si des identifiants ont été fournis, le serveur les considère comme insuffisants – et le client ne doit pas rejouer automatiquement la même requête ;
• une requête peut être refusée pour des raisons sans lien avec l’authentification.

Ce troisième point est le plus important. Une erreur 403 peut frapper une requête parfaitement authentifiée : mauvais rôle, mauvais périmètre, mauvaise heure, mauvaise adresse IP, règle géographique, quota, restriction de méthode HTTP.

Pourquoi le serveur refuse au lieu de dire « introuvable »

Certains administrateurs préfèrent répondre 404 là où le code attendu serait 403. L’objectif est contre-intuitif mais sain : ne pas révéler l’existence d’une ressource à un client qui n’a pas les droits de la voir. MDN le documente explicitement comme un choix possible.

Conséquence pratique : si vous voyez une 404 alors que vous savez que la page existe, il n’est pas absurde d’imaginer une 403 déguisée. Le raisonnement inverse est faux : une 403 n’est jamais une simple page manquante.

Les libellés que vous verrez à l’écran

Le message varie selon le serveur, le CMS, l’hébergeur et le pare-feu. Les formes les plus courantes :

• 403 Forbidden
• HTTP Error 403
• Access Denied
• You don't have permission to access this resource
• Forbidden: You don't have permission to access / on this server
• Error 403 – Forbidden
• Blocked due to access forbidden (403)
• un message signé Cloudflare, ModSecurity ou l’hébergeur, parfois accompagné d’un Ray ID

Le libellé est une information exploitable. Une page 403 signée par le CDN ne vient pas de votre serveur d’origine. Une page 403 générique et sans marque vient presque toujours de l’origine.

Ce que l’erreur 403 n’est pas

Trois confusions reviennent en permanence et font perdre du temps.

• Ce n’est pas une page supprimée. Une page supprimée renvoie 404 ou 410. Une 403 dit « accès refusé », pas « contenu absent ».
• Ce n’est pas une erreur de votre navigateur, sauf en apparence : le navigateur affiche le refus, il ne le provoque pas. Seules les données locales (cache, cookies, session) peuvent indirectement déclencher un refus côté serveur.
• Ce n’est pas forcément une panne à corriger. Une zone membre, un panneau d’administration, un dossier de sauvegardes ou une API interne peuvent légitimement renvoyer 403 à tout le monde. Un refus attendu n’est pas un incident.

Erreur 403, 401 ou 404 : comment ne plus confondre les trois codes

Les internautes confondent les trois codes, et le malentendu coûte cher : la page Wikipedia sur le HTTP 403 et la documentation MDN figurent d’ailleurs en haut des résultats français, précisément parce que la demande est d’abord définitionnelle. Voici la lecture qu’il faut retenir.

401 Unauthorized : le serveur attend une identification

Le 401 est un portier qui demande un badge. La réponse contient normalement un en-tête WWW-Authenticate qui indique la méthode attendue. Une fois le badge présenté et accepté, l’accès s’ouvre. Si vous vous reconnectez et que le refus persiste, la cause est ailleurs.

403 Forbidden : le serveur vous a reconnu et refuse quand même

Le 403 est un portier qui a lu votre badge, l’a reconnu, et vous demande de repartir. Le badge est peut-être périmé, certes, mais surtout il est insuffisant : vous n’appartenez pas au groupe autorisé. Renouveler l’identification ne servira à rien tant que la règle d’autorisation n’aura pas changé.

404 Not Found : la ressource n’existe pas ou plus

Le 404 indique que le serveur ne trouve aucun contenu associé à l’URL demandée. Il n’y a pas de question de droit : soit le fichier a été déplacé, soit l’URL est mal écrite, soit le routage est cassé.

Le 403 déguisé en 404 : un choix de sécurité assumé

Certaines configurations répondent 404 là où le code naturel serait 403, pour ne pas confirmer l’existence d’une ressource sensible. C’est une pratique légitime. Le repère de lecture reste le même : si la page existe réellement chez vous mais renvoie « introuvable », la piste n’est pas la disparition, mais la restriction.

Comment trancher en trente secondes

Trois gestes suffisent, dans cet ordre.

1. Déconnectez-vous et rechargez. Si l’accès s’ouvre, le problème est de type 401 : rôle ou session.
2. Comparez deux URL du même dossier. Si une seule échoue, la cause est locale. Si tout le dossier échoue, la cause est une règle.
3. Testez depuis un autre réseau. Si l’erreur disparaît, vous êtes bloqué par IP, par pays ou par réputation d’adresse.

Et si le message n’est pas un code HTTP ?

Tous les refus du quotidien ne sont pas des 403. Un serveur qui ferme la connexion sans rien renvoyer produit une ERR_EMPTY_RESPONSE, qui se diagnostique côté infrastructure plutôt que côté autorisation. Un tunnel TLS mal négocié produit un SSL handshake failed ou une erreur ERR_SSL_PROTOCOL_ERROR.

Un blocage par un pare-feu local ressemble fortement à une 403 sans en être une d’un point de vue HTTP. Ces cas sont traités séparément dans nos guides dédiés – lien vers le cluster en fin d’article.

Pourquoi une erreur 403 apparaît-elle ? 8 causes réelles, classées par fréquence

Une erreur 403 apparaît quand une règle refuse l’accès à une ressource. Rien de plus, rien de moins. Mais cette règle peut vivre à six endroits différents : dans les permissions du système de fichiers, dans la configuration du serveur web, dans le CMS, dans le pare-feu applicatif, dans la résolution DNS ou dans le code de l’application.

Confondre ces niveaux est la première cause d’échec. On modifie des permissions alors que le blocage vient du WAF, ou on désactive le WAF alors qu’une seule ligne du .htaccess suffisait.

Cause 1 – Permissions et propriété des fichiers

C’est la cause la plus enseignée, et l’une des plus mal appliquées. Le serveur web tourne sous un utilisateur système précis. Si cet utilisateur n’a pas le droit de lire un fichier ou de traverser un dossier, le serveur répond 403 – pas une erreur 500, pas une page blanche.

Les permissions reconnues

Pourquoi 777 est une fausse solution

Passer un dossier en 777 « débloque » souvent l’accès. C’est un aveu, pas un correctif. Vous rendez un dossier accessible en écriture à tous les utilisateurs du serveur, ce qui ouvre la porte à l’injection de fichiers et à la défiguration. Un site corrigé en 777 est un site en sursis.

Cause 2 – Fichier .htaccess ou configuration serveur trop restrictive

Sur Apache, le fichier .htaccess applique des règles par dossier, sans redémarrage du serveur. Une seule ligne mal placée bloque tout : Require all denied, un Deny from all hérité de l’ancienne syntaxe, une restriction sur un dossier d’uploads, une règle de réécriture qui envoie vers une cible protégée.

Les directives qui bloquent réellement

Comment isoler la directive fautive

Renommez .htaccess en .htaccess.bak. Rechargez. Si le site revient, la cause est dans le fichier. Réintroduisez ensuite les blocs par moitié jusqu’à identifier la ligne coupable – la dichotomie fonctionne mieux que la lecture intégrale d’un long fichier.

Cause 3 – Plugin, thème ou restriction de rôle dans le CMS

WordPress et les CMS à plugins empilent des couches de sécurité. Un plugin anti-bruteforce, un module de contrôle d’accès, un gestionnaire de membres ou un plugin de sauvegarde peuvent bloquer /wp-admin/, /wp-login.php, l’API REST, XML-RPC, une plage d’IP ou un pays entier.

Le thème peut aussi porter une condition d’accès mal écrite dans functions.php et refuser tout le monde.

Cause 4 – WAF, pare-feu et CDN

Un pare-feu applicatif web analyse la requête avant qu’elle n’atteigne l’origine. Une signature agressive, un faux positif, un mode anti-bot ou une règle géographique produisent une 403 parfaitement légitime du point de vue du WAF – et parfaitement illégitime du point de vue du visiteur légitime.

C’est la cause la plus sous-estimée, parce qu’elle n’apparaît dans aucun fichier du site. Notre guide complet sur le pare-feu détaille cette couche.

Cause 5 – Adresse IP, plage ou réputation bloquée

Le blocage peut viser une IP unique, une plage, un datacenter entier ou un hébergeur VPN. Le repère est net : l’erreur suit l’utilisateur, pas la page. Le même lien fonctionne sur un autre réseau, échoue systématiquement sur le vôtre.

Cause 6 – Absence de fichier index et liste de répertoire désactivée

Quand un visiteur demande un dossier sans fichier index.html, index.php ou index.htm, et que la liste des fichiers est interdite (Options -Indexes), le serveur n’a rien à servir. Selon la configuration, il répond 403. Ce n’est pas un bug : c’est une protection contre la divulgation de l’arborescence.

Cause 7 – DNS, vhost ou migration mal terminée

Après une migration, le domaine peut pointer vers un serveur qui ne contient pas le bon site, ou vers un répertoire racine mal déclaré. Le serveur répond alors 403 parce qu’il n’a rien d’autorisé à servir à cette adresse. Symptôme typique : seul www échoue, ou seul le sous-domaine est touché.

Cause 8 – Restriction volontaire d’une ressource

Toute 403 n’est pas un incident. Une API peut refuser un jeton aux périmètres insuffisants, un dossier d’uploads peut interdire le hotlink, une page peut être réservée à un rôle, une ressource statique peut être protégée par Referrer-Policy. Avant de corriger, vérifiez que le refus n’est pas décidé.

Diagnostic rapide : d’où vient votre erreur 403 ?

Une erreur 403 ne doit jamais être corrigée à l’aveugle. La séquence ci-dessous élimine la majorité des fausses pistes avant toute modification.

L’erreur touche-t-elle d’autres personnes ?

Erreur 403 Forbidden
            |
            v
L'erreur touche-t-elle d'autres personnes ?
      /                         \
    NON                         OUI
     |                           |
Votre poste ou votre réseau   Le site ou l'infrastructure
     |                           |
     v                           v
Cache, cookies, session       Permissions / .htaccess / Nginx
     |                           |
     v                           v
VPN, proxy, extension         WAF, CDN, pare-feu applicatif
     |                           |
     v                           v
Autre réseau, autre appareil  DNS, vhost, racine du site
     |                           |
     v                           v
Toujours bloqué ?             Logs serveur : quel motif exact ?
     |                           |
     v                           v
IP ou compte bloqué           Corriger la règle, pas la serrure

La question qui élimine la moitié des pistes

Qui est refusé ? Un seul visiteur, tous les visiteurs, un robot, un service tiers, une API. Tant que cette réponse n’est pas posée, les correctifs s’empilent sans méthode. Un refus dont vous êtes le seul témoin se traite côté navigateur. Un refus collectif se traite côté serveur.

Le test de discrimination en trois minutes

1. Navigation privée : si l’accès revient, la cause est locale (cache, cookies, extension).
2. Second navigateur sur un autre réseau : si l’accès revient, la cause est réseau ou IP.
3. Curl en ligne de commande : curl -I https://exemple.com/page révèle le code de statut réel, sans interface graphique ni cache applicatif.

Ces trois gestes ne corrigent rien, mais ils orientent tout. C’est le meilleur rapport temps/information du diagnostic.

Lire les logs : la seule preuve qui compte

Le log est le seul endroit où le serveur dit pourquoi il refuse. Tout le reste est interprétation.

Logs d’accès (Apache et Nginx)

Cherchez les réponses en 403 et notez l’IP, l’user-agent, l’URL exacte, l’heure et le référent. Vous distinguez immédiatement un visiteur isolé d’un crawler, et une URL isolée d’un dossier entier.

Logs d’erreur, deny_log et journal ModSecurity

Apache peut journaliser séparément les refus. ModSecurity, lui, écrit l’identifiant de la règle déclenchée ([id "..."]) et le motif : c’est la preuve la plus directe qui existe. Sans cet identifiant, l’hébergeur vous répondra « on a débloqué », et le blocage reviendra au prochain crawl.

Logs Nginx

L’erreur directory index of "/chemin" is forbidden désigne sans ambiguïté l’absence de fichier index. access forbidden by rule désigne une directive deny. Deux messages, deux correctifs radicalement différents.

Contexte observé → première action

Comment corriger une erreur 403 Forbidden ? 14 méthodes détaillées

Les solutions ci-dessous sont classées du plus rapide au plus technique. Dans les cas que nous avons traités, les six premières règlent la grande majorité des situations côté visiteur et côté éditeur débutant ; les huit suivantes visent la configuration serveur, les migrations et les infrastructures protégées.

Méthode 1 – Vérifier l’URL exacte et le contexte d’accès

Une 403 peut simplement signaler que vous demandez une ressource dont l’accès direct est interdit. Vérifiez d’abord l’adresse elle-même.

Comment vérifier

1. Relisez l’URL caractère par caractère.
2. Respectez la casse : sur Linux, /Images/ et /images/ sont deux chemins différents.
3. Supprimez les paramètres de suivi ajoutés par un réseau social ou un e-mail.
4. Testez la version avec et sans slash final.
5. Cherchez la page depuis le menu interne du site plutôt que par l’URL directe.

Erreur à éviter

Ne modifiez pas les permissions parce qu’un dossier refuse le listing. https://exemple.com/uploads/ qui renvoie 403 est souvent un comportement attendu. L’anomalie commence quand l’image précise à l’intérieur du dossier renvoie également 403.

Méthode 2 – Recharger, puis tester en navigation privée

Une 403 temporaire peut venir d’une session expirée, d’un jeton de formulaire périmé ou d’une règle anti-rejeu déclenchée par un double envoi.

Étapes

1. Rechargez avec Ctrl + F5 (Windows, Linux) ou Cmd + Shift + R (macOS).
2. Ouvrez une fenêtre privée.
3. Collez l’URL exacte, sans être connecté.
4. Recommencez en étant connecté.
5. Comparez les deux résultats.

Ce que le résultat signifie

Si l’accès passe en navigation privée, la cause est dans votre profil : cache, cookies, extension. Si la page est accessible connecté mais refusée déconnecté, vous tenez une restriction de rôle – donc une 403 attendue.

Méthode 3 – Vider le cache et supprimer les cookies du site

Des cookies corrompus ou un cache obsolète peuvent faire échouer une requête légitime, notamment après un changement de CDN, d’hébergement ou de mécanisme de connexion.

Périmètre à effacer

Le point important : effacez les cookies du domaine concerné, pas l’intégralité de votre navigateur. Vous gardez vos autres sessions intactes. Si le problème persiste après cette manipulation, la cause n’est pas locale – un cache navigateur qui refuse une requête valide est un symptôme de ERR_CACHE_MISS plutôt qu’une 403 à proprement parler.

Méthode 4 – Désactiver VPN, proxy, bloqueur de publicité et extensions

Beaucoup de sites bloquent les plages d’adresses de datacenters, de VPN et de proxys, parce qu’elles servent massivement au scraping et aux tentatives automatisées.

Protocole de test

1. Coupez le VPN.
2. Désactivez le proxy système.
3. Mettez le bloqueur de publicité en pause sur ce domaine.
4. Désactivez les extensions par moitié, pas une par une.
5. Testez en partage de connexion mobile.
6. Recommencez depuis un autre appareil.

Lecture du résultat

Si l’erreur disparaît sans VPN, votre adresse de sortie était bloquée. Si elle disparaît sans extension, l’extension modifiait vos en-têtes. Si elle persiste partout, la cause est côté serveur. Sur ce terrain, distinguez bien les messages : un blocage réseau produit souvent un ERR_CONNECTION_TIMED_OUT ou un ERR_CONNECTION_RESET plutôt qu’un code HTTP 403.

Méthode 5 – Vérifier si votre adresse IP est bloquée

Le blocage peut venir d’une décision humaine (une règle ajoutée à la main) ou d’un automatisme (réputation, seuil de requêtes, pays).

Où chercher

• Plugin de sécurité du CMS ;
• pare-feu applicatif de l’hébergeur ;
• WAF du CDN ;
• fichier .htaccess ;
• configuration Nginx ou Apache ;
• outil anti-DDoS.

Comment confirmer

1. Testez depuis un autre réseau.
2. Faites tester par une personne d’une autre région.
3. Consultez l’historique de blocage du pare-feu.
4. Cherchez votre IP dans les règles actives.
5. Demandez à l’hébergeur le motif d’un éventuel blocage.

Erreur à éviter

Ne supprimez pas une règle de blocage en bloc. Retirez la seule entrée fautive. Une suppression large ouvre le site que vous cherchiez précisément à protéger.

Méthode 6 – Corriger les permissions des fichiers et dossiers

Des droits trop restrictifs empêchent le serveur de lire un fichier ou de traverser un dossier. Le résultat est une 403 sur une page, un dossier ou l’ensemble du site.

Via un client FTP

1. Connectez-vous à la racine du site.
2. Sélectionnez les dossiers, corrigez à 755 (ou 750).
3. Sélectionnez ensuite les fichiers, corrigez à 644 (ou 640).
4. Traitez les dossiers avant les fichiers.
5. Testez la page concernée.

Via SSH

find /chemin/du/site -type d -exec chmod 755 {} \;
find /chemin/du/site -type f -exec chmod 644 {} \;

Ces commandes sont récursives et donc sensibles. Sauvegardez avant, et vérifiez le chemin deux fois.

Erreur critique à éviter

Pas de 777, pas de chmod -R 777, jamais. Le confort immédiat se paie en surface d’attaque.

Méthode 7 – Vérifier la propriété (ownership) des fichiers

Les permissions peuvent être parfaites et l’erreur persister : si les fichiers appartiennent à un utilisateur système différent de celui du serveur web, la lecture échoue quand même.

Situations typiques

• migration d’hébergeur ;
• restauration de sauvegarde ;
• transfert FTP réalisé avec un mauvais compte ;
• installation manuelle du CMS ;
• intervention SSH mal ciblée.

Symptômes

• les permissions semblent correctes, la 403 persiste ;
• les médias ne s’affichent plus ;
• les mises à jour du CMS échouent ;
• le site fonctionne partiellement.

Que faire

ls -la          # vérifier l'utilisateur et le groupe propriétaires
chown -R utilisateur:groupe /chemin/du/site

Sur un hébergement mutualisé, la commande est rarement accessible : demandez explicitement au support une vérification de l’ownership. Une erreur de chown casse plus de choses que l’erreur 403 initiale.

Méthode 8 – Sauvegarder puis régénérer le fichier .htaccess

Une seule directive incorrecte suffit à bloquer une page, un dossier ou le site entier. Le .htaccess est aussi le fichier que les plugins modifient sans prévenir.

Quelques lignes qui bloquent

Require all denied
Order deny,allow
Deny from all

À retenir : Require all denied refuse l’accès au dossier. Options -Indexes interdit seulement la liste des fichiers. Confondre les deux conduit à « corriger » une 403 par une autre 403.

Procédure de test

1. Téléchargez une copie de sauvegarde du fichier.
2. Renommez-le en .htaccess.bak.
3. Rechargez le site.
4. Si le site revient, réintroduisez les blocs par moitié.
5. Régénérez un fichier propre.

Régénération sous WordPress

Allez dans Réglages → Permaliens, ne changez rien, cliquez sur Enregistrer les modifications. WordPress réécrit un .htaccess conforme, et le bloc fautif disparaît – c’est le correctif le plus rapide de cette liste.

Méthode 9 – Rétablir un fichier index dans le dossier

Un dossier sans fichier d’accueil et dont la liste est interdite ne peut pas être servi. Le serveur répond alors 403.

Les fichiers d’accueil reconnus

index.html, index.htm, index.php selon la directive DirectoryIndex du serveur.

Procédure

1. Identifiez le dossier concerné dans l’URL.
2. Ajoutez un fichier d’accueil minimal.
3. Vérifiez ses permissions (644).
4. Testez l’URL.
5. Contrôlez la directive DirectoryIndex si le problème persiste.

Erreur à éviter

Ne réactivez pas l’affichage des répertoires pour « faire disparaître » la 403. Vous rendriez publique l’arborescence du site – donc vos sauvegardes, vos fichiers de configuration et vos historiques.

Méthode 10 – Désactiver temporairement les extensions du CMS

Un plugin de sécurité, de cache, de redirection ou de restriction de contenu peut bloquer une page après une mise à jour ou un changement de réglage.

Avec accès au tableau de bord

1. Extensions → Extensions installées.
2. Désactivez tout.
3. Rechargez la page qui échouait.
4. Réactivez par moitié en testant à chaque étape.

Sans accès au tableau de bord

1. Connectez-vous en FTP.
2. Ouvrez /wp-content/.
3. Renommez plugins en plugins_off.
4. Testez le site.
5. Recréez un dossier plugins propre et réactivez progressivement.

Conseil

Désactivez, ne supprimez pas. La suppression efface aussi les réglages, et parfois les données associées.

Méthode 11 – Tester un thème par défaut

Un thème peut porter une condition d’accès erronée dans functions.php et refuser tous les visiteurs, administrateurs compris.

Procédure

1. Sauvegardez le site.
2. Apparence → Thèmes, activez un thème officiel par défaut.
3. Testez la page concernée.
4. Si l’erreur disparaît, le thème était en cause : inspectez functions.php et les réglages d’accès.
5. Sinon, rétablissez votre thème et poursuivez ailleurs.

Précision utile

Sur un site construit avec un constructeur de pages, le changement de thème peut modifier temporairement l’affichage. Ce désagrément est acceptable pendant un diagnostic ; il faut simplement le savoir avant de paniquer.

Méthode 12 – Auditer le CDN, Cloudflare et le WAF

Si le site passe par un CDN ou un pare-feu applicatif, la 403 peut être générée avant l’origine. Le serveur n’a alors rien à corriger : la règle est ailleurs.

Pistes classiques

• règle WAF trop large ;
• blocage par pays ;
• blocage d’IP ou de plage ;
• mode anti-bot ;
• règle personnalisée héritée d’un test ;
• protection hotlink ;
• challenge échoué ;
• origine qui refuse les adresses IP du CDN.

Procédure de diagnostic

1. Regardez si la page d’erreur porte la marque du CDN.
2. Notez le Ray ID s’il est affiché.
3. Ouvrez les événements de sécurité dans la console du CDN.
4. Identifiez la règle exacte déclenchée.
5. Testez un sous-domaine hors proxy pour comparer.
6. Vérifiez que l’origine autorise les plages du CDN.

Erreur à éviter

Ne désactivez pas le WAF pour « voir ». Ajustez la règle fautive. Un WAF coupé résout aujourd’hui et expose demain. Si le blocage accompagne un problème de certificat, orientez-vous plutôt vers le diagnostic d’une erreur 526 liée au certificat SSL.

Méthode 13 – Vérifier DNS, enregistrement A et racine du serveur

Après une migration ou un changement DNS, le domaine peut pointer vers un serveur qui ne connaît pas ce site. Ce serveur répond 403 faute de contenu autorisé à servir.

Vérifications

1. Comparez l’IP annoncée par l’hébergeur et l’enregistrement A réel.
2. Vérifiez les nameservers.
3. Contrôlez la version www et la version racine séparément.
4. Vérifiez le DocumentRoot ou la racine associée au domaine.
5. Laissez la propagation DNS se terminer avant de conclure.

Repère de lecture

Une erreur qui touche uniquement un sous-domaine ou uniquement www est presque toujours une histoire de vhost, de certificat ou de DNS. Ce n’est ni un plugin, ni une permission. Dans cette famille de symptômes, un DNS_PROBE_STARTED ou un échec de résolution ressemble souvent à un blocage alors qu’il n’en est pas un.

Méthode 14 – Contacter l’hébergeur avec le bon dossier de preuves

Certaines 403 ne se diagnostiquent pas depuis l’interface d’administration : les règles ModSecurity, les logs système et les limites de compte restent côté hébergeur.

Éléments à fournir

• l’URL exacte qui échoue ;
• l’heure précise de l’erreur (avec fuseau) ;
• votre adresse IP publique ;
• le code de statut obtenu via curl -I ;
• les tests déjà réalisés et leur résultat ;
• une capture d’écran du message ;
• les dernières modifications sur le site ;
• la présence éventuelle d’un CDN.

Exemple de message au support

Bonjour,

Mon site renvoie une erreur 403 Forbidden sur l’URL [URL] depuis le [date et heure].

J’ai déjà testé : cache navigateur, autre réseau, désactivation des plugins, régénération du .htaccess. Le test curl -I renvoie toujours 403.

Pouvez-vous vérifier les logs serveur, les règles ModSecurity/WAF, les permissions et l’ownership des fichiers, ainsi qu’un éventuel blocage IP ?

Pourquoi cette méthode fonctionne

Un support reçoit des centaines de « mon site ne marche pas ». Un ticket qui contient le code de statut, l’heure et la liste des tests déjà faits passe en tête. Vous transformez une demande en diagnostic.

Récapitulatif des 14 méthodes

Cas WordPress : corriger une erreur 403 sur wp-admin ou sur le site

WordPress cumule tout ce qui peut produire une 403 : fichiers, base de données, extensions, thèmes, permaliens, .htaccess, API REST, XML-RPC, rôles utilisateurs et règles de sécurité. C’est pourquoi un diagnostic WordPress doit avancer par couches, pas par intuition.

Tableau de diagnostic WordPress

Procédure WordPress recommandée

1. Sauvegardez fichiers et base de données.
2. Videz le cache du site et celui du CDN.
3. Régénérez les permaliens (Réglages → Permaliens → Enregistrer).
4. Désactivez les extensions, par moitié.
5. Testez un thème par défaut.
6. Vérifiez le .htaccess (comparaison avec un fichier propre).
7. Vérifiez les permissions et l’ownership.
8. Contrôlez la configuration wp-config.php.
9. Examinez le CDN et les règles de sécurité.
10. Lisez les logs serveur avant de conclure.

Permissions WordPress : les valeurs de référence

Pourquoi la régénération des permaliens suffit parfois

Certains plugins réécrivent le .htaccess en y ajoutant leurs propres règles. Après une mise à jour ou une désinstallation incomplète, une ligne orpheline subsiste et bloque un dossier. En enregistrant à nouveau les permaliens, WordPress reconstruit un fichier propre et la ligne disparaît. C’est le correctif le plus rapide, et le plus souvent négligé.

Quand il faut sortir de l’interface d’administration

Si la 403 bloque /wp-admin/, vous ne pouvez rien corriger depuis l’interface. Il reste trois accès : FTP ou gestionnaire de fichiers, cPanel ou Plesk, SSH. Renommer le dossier plugins par FTP est le geste de sauvetage le plus fiable : WordPress désactive alors toutes les extensions, et vous réactivez par dichotomie ensuite.

API REST et XML-RPC : les 403 invisibles

Deux zones produisent des 403 sans que le propriétaire du site les voie jamais : l’API REST (/wp-json/) et XML-RPC (/xmlrpc.php). Beaucoup de règles de sécurité les bloquent globalement pour tarir les attaques.

Effet secondaire : les outils légitimes qui s’appuient dessus – applications mobiles, éditeurs hors ligne, connecteurs de newsletter, outils de publication automatisée – tombent en 403. Si une intégration cesse de fonctionner sans qu’aucune page ne soit cassée, cherchez ici en premier.

Retours du terrain : 5 cas réels d’erreur 403 et ce qui les a résolus

Les listes génériques ne disent pas ce qui se passe vraiment. Voici cinq situations rencontrées lors de tests et d’audits, avec le symptôme, ce que disaient les logs, le correctif appliqué et ce qu’il faut en retenir.

Cas 1 – WordPress : un plugin de sécurité qui bloque tout le monde

Symptôme : une semaine après une mise à jour d’extension, /wp-admin/ renvoie une 403 pour tous les comptes, y compris l’administrateur. Le site public reste accessible.

Ce que disaient les logs : des entrées ModSecurity avec un identifiant de règle constant, sur les requêtes vers /wp-admin/ uniquement.

Le correctif : désactivation du dossier plugins par FTP, réactivation une par une. Le plugin de sécurité déclenchait une règle modifiée par sa propre mise à jour, avec un seuil de requêtes devenu absurde. Exclusion de /wp-admin/ après authentification.

Ce qu’on retient : si la 403 bloque l’administration, elle ne se corrige pas depuis l’administration. Le FTP est un plan B obligatoire.

Cas 2 – Cloudflare : une règle WAF plus large que prévu

Symptôme : environ 15 % des visiteurs signalent une 403, sans logique apparente. Aucun pattern de navigateur, de pays ni d’heure. La direction ne reproduit jamais le problème.

Ce que disaient les logs : rien côté origine. La requête n’arrivait tout simplement pas au serveur.

Le correctif : consultation des événements de sécurité du CDN. Une règle personnalisée « bloque le motif dans l’URL » capturait un paramètre de campagne légitime. La règle affichait un score bas, mais bloquait bien en dur. Réécriture de la règle en mode journalisation d’abord, puis en mode blocage après vérification.

Ce qu’on retient : quand les logs d’origine sont vides, le blocage est en amont. Le Ray ID est la seule passerelle vers la preuve.

Cas 3 – Hébergement mutualisé : un ownership cassé après migration

Symptôme : après un changement d’hébergeur, le site fonctionne, mais les médias renvoient 403. Les permissions affichées sont pourtant exemplaires : dossiers en 755, fichiers en 644.

Ce que disaient les logs : un refus de lecture sur les fichiers du dossier uploads, sans autre détail.

Le correctif : signalement au support de l’hébergeur. Les fichiers appartenaient à un utilisateur système hérité de la migration, pas à l’utilisateur du serveur web. Un chown récursif côté hébergeur a tout rétabli, sans toucher aux permissions.

Ce qu’on retient : permissions correctes plus ownership incorrect égalent 403. Sur du mutualisé, seul l’hébergeur peut corriger.

Cas 4 – API : un jeton valide, mais au mauvais périmètre

Symptôme : une intégration interne renvoie 403 sur un endpoint qui fonctionnait la veille. Le jeton n’a pas expiré, l’authentification passe.

Ce que disaient les logs : requête authentifiée avec succès, puis refus au moment du contrôle d’autorisation.

Le correctif : comparaison des périmètres du jeton avec les droits exigés par l’application. Un droit de lecture global avait été remplacé par un droit de lecture limité à un sous-ensemble de ressources lors d’un changement de règle. Ajout du périmètre minimal nécessaire.

Ce qu’on retient : un 403 sur une API authentifiée n’est jamais un problème d’authentification. C’est un problème de rôle, de scope ou de politique.

Cas 5 – Googlebot bloqué par un filtre anti-bot trop zélé

Symptôme : aucune plainte visiteur, mais les impressions chutent en Search Console. L’inspection d’URL signale « Explorée, actuellement non indexée » ou une erreur d’accès.

Ce que disaient les logs : des 403 ciblant l’user-agent de Googlebot sur une partie du site seulement – les pages de catégories.

Le correctif : une règle anti-bot filtrait les requêtes sans Referer sur certaines arborescences. Googlebot n’envoie pas toujours de référent. La règle a été restreinte aux chemins réellement sensibles, et la vérification a été relancée via l’inspection d’URL.

Ce qu’on retient : une 403 invisible pour les humains peut coûter l’indexation. Search Console est un détecteur de pannes silencieuses.

Erreur 403 et SEO : quel impact dans Google Search Console ?

Une 403 n’a pas toujours un coût SEO. Elle en a un dès qu’elle touche une URL publique destinée à être indexée, ou une ressource nécessaire au rendu d’une page.

Ce que Google fait d’une URL en 403

Google n’utilise pas le contenu d’une URL renvoyant un code de la famille 4xx pour l’indexation. Une URL déjà indexée qui renvoie durablement un 4xx peut être progressivement retirée de l’index. Le contenu n’est pas « vu comme non autorisé » : il est simplement traité comme inaccessible, donc inexploitable.

Ce que dit Search Console

Le rapport Indexation → Pages regroupe les motifs. Les libellés utiles à connaître :

• Bloquée pour cause d’accès interdit (403) ;
• Explorée, actuellement non indexée ;
• Introuvable (404) ;
• Erreur de serveur (5xx).

La procédure de contrôle :

1. Ouvrez Inspection de l’URL sur l’adresse concernée.
2. Lancez le test en direct.
3. Lisez le code de statut obtenu par Googlebot.
4. Comparez avec ce que vous observez, vous, dans votre navigateur.
5. Si Googlebot reçoit 403 et vous non, la cause est un filtrage de robot.

Le cas de la 403 légitime

Une zone membre, un panier, un espace client, un dossier de sauvegardes, une API interne : ces ressources peuvent renvoyer 403 sans aucun problème SEO. L’enjeu n’est pas de supprimer toutes les 403, mais de corriger celles qui frappent des pages publiques et des ressources de rendu.

Erreur 403 sur un sitemap ou sur une ressource

Deux angles morts fréquents :

• un sitemap XML qui déclare des URL renvoyant 403 ;
• des ressources (CSS, JS, polices) bloquées, qui empêchent le rendu correct de la page côté robot même si le HTML répond 200.

Le second cas est le plus pernicieux : Search Console ne signale pas toujours une erreur explicite, mais le rendu diffère, et la qualité d’indexation se dégrade.

Procédure de sortie : de la 403 à l’indexation

1. Identifier la règle fautive (logs, événements du CDN).
2. Corriger la règle sans ouvrir plus large que nécessaire.
3. Vérifier en test en direct depuis Search Console.
4. Confirmer le passage en 200 (ou en 301 vers une cible valide).
5. Demander une nouvelle exploration sur les URL stratégiques.
6. Surveiller le rapport d’indexation pendant deux à quatre semaines.

Ce qu’il ne faut pas faire

N’utilisez pas une 403 comme outil de régulation d’exploration. Google le précise : les codes 4xx ne servent pas à limiter la charge. Le code prévu pour une surcharge temporaire est 429, avec un en-tête Retry-After. Bloquer en 403 pour « ralentir » un robot, c’est risquer de perdre l’indexation que vous vouliez protéger.

Comment prévenir les erreurs 403 à l’avenir ?

L’objectif n’est pas d’ouvrir tous les accès. C’est de garantir que les bonnes ressources restent accessibles aux bonnes personnes, aux bons robots et aux bons services.

1. Auditer régulièrement les permissions

Notez la valeur de référence de chaque type de fichier et vérifiez-la après chaque migration, restauration ou intervention d’un tiers. Une anomalie détectée en une minute évite une panne détectée en une journée.

2. Sauvegarder .htaccess avant toute modification

Ce fichier est capable de couper le site entier en une ligne. Conservez systématiquement une copie datée, et testez la modification juste après l’avoir appliquée.

3. Documenter chaque règle de blocage

Toute règle WAF, tout blocage d’IP, tout filtrage d’user-agent doit avoir un commentaire : qui l’a posée, pourquoi, et à quelle date. Une règle orpheline oubliée pendant six mois produit une 403 inexplicable – jusqu’à ce que quelqu’un pense à regarder la console du CDN.

4. Tester les points critiques après chaque mise à jour

Après chaque mise à jour de plugin, de thème ou de CMS, testez : page d’accueil, pages stratégiques, /wp-admin/, formulaire de connexion, sitemap, ressources CSS et JS, API REST si elle est utilisée.

5. Contrôler le CDN après chaque changement de réglage

Activez d’abord les nouvelles règles en mode journalisation, puis en mode blocage. Testez depuis plusieurs réseaux et plusieurs pays avant de considérer le réglage comme stabilisé.

6. Surveiller Search Console hebdomadairement

Une hausse d’erreurs d’accès interdit sur des URL publiques se voit en quelques jours. Un simple coup d’œil hebdomadaire au rapport d’indexation évite une désindexation de plusieurs semaines.

7. Mettre en place une supervision technique

Un simple contrôle externe qui teste le code de statut de vos dix URL principales et vous alerte en cas de 403 détecte ce que Search Console signale trop tard. Combinez-le avec une sonde sur les ressources statiques : ce sont les 403 les plus difficiles à voir à l’œil nu.

8. Réserver le blocage aux chemins réellement sensibles

La cause la plus fréquente d’erreur 403 accidentelle reste la règle posée trop large. Ciblez des chemins précis plutôt que des règles globales, et préférez un refus explicite à un blocage silencieux. Sur ce point, une politique de pare-feu bien documentée vaut mieux qu’une collection de règles ajoutées au fil des incidents.

Erreur 403 : les cas particuliers qui piègent le diagnostic

Certaines 403 échappent aux schémas habituels. Elles partagent un point commun : elles ne suivent pas la logique « une page, un problème ».

Erreur 403 uniquement sur mobile

Deux pistes dominent : un filtrage sur l’user-agent mobile, ou une application embarquée (WebView) qui envoie des en-têtes différents du navigateur standard. Testez la même URL dans le navigateur du téléphone, pas dans l’application. Si la page passe dans le navigateur mais pas dans l’application, la cause est le client, pas le site.

Erreur 403 sur une API malgré un jeton valide

Rejouez l’appel en ligne de commande, avec l’en-tête Authorization complet, et comparez avec ce qu’envoie le client fautif. Le diagnostic se joue sur trois éléments : la méthode HTTP, le périmètre du jeton et le rôle associé. Un jeton valide sans droit sur la ressource produit un 403 parfaitement normal.

Erreur 403 derrière un pare-feu d’entreprise

Les proxys d’entreprise avec inspection TLS réécrivent les requêtes et modifient les en-têtes. Résultat : une 403 sur plusieurs sites, jamais sur le réseau mobile, jamais à la maison. Le test décisif est le changement de réseau – pas la modification du site, qui n’y est pour rien.

Erreur 403 en développement local

Un serveur local configuré avec Require all denied, un DirectoryIndex absent ou un vhost mal nommé produit exactement les mêmes symptômes qu’en production. La différence : ici, vous avez le contrôle total de la configuration. Lisez le fichier de configuration avant de chercher un plugin coupable.

Erreur 403 sur une ressource statique

Une police, une feuille de style ou un script qui renvoie 403 casse le rendu sans produire de message visible pour l’utilisateur. Ouvrez l’onglet réseau du navigateur : les requêtes en rouge racontent l’histoire. Les causes habituelles sont une règle de dossier trop stricte, une Referrer-Policy mal alignée avec une protection anti-hotlink, ou un en-tête CORS absent sur un sous-domaine de ressources.

Erreur 403 et tunnel TLS

Quand le refus arrive avec un problème de certificat ou de négociation, le diagnostic change complètement. Un SSL handshake failed ou une erreur ERR_SSL_PROTOCOL_ERROR se traite côté certificat, protocoles et chaîne d’autorité, pas côté autorisation.

Un CDN en mode SSL « Full (strict) » avec un certificat d’origine invalide produit d’ailleurs une erreur dédiée, la erreur 526, qui est souvent confondue avec une 403.

Notre verdict : qui doit corriger, l’éditeur ou le visiteur ?

Notre position, après avoir traité ces cas : une erreur 403 récurrente est presque toujours une dette technique de l’éditeur, pas un problème du visiteur. Le visiteur subit un refus qu’il ne peut ni comprendre ni contourner. Le site, lui, a posé la règle.

Ce que la répartition de nos cas montre

Notre position

Côté visiteur, cinq gestes suffisent : recharger, tester en navigation privée, vider les cookies du site, couper le VPN, changer de réseau. Si rien ne bouge, ce n’est plus votre problème – et vous ne pourrez pas le résoudre.

Côté éditeur, la responsabilité est entière. Une règle de sécurité doit être précise, documentée et testée. Un message d’erreur 403 générique, sans indication, sans page de contact, sans explication, est une faute de conception : il renvoie au visiteur une frustration que le site a créée. Les meilleurs sites que nous auditions affichent une page 403 personnalisée qui explique le refus, propose une action et laisse un contact.

Ce que nous refusons

Nous refusons deux pratiques courantes. Premièrement, l’ouverture maximale : 777 partout, WAF coupé, WAF désactivé pour faire taire une alerte. On échange une erreur visible contre une faille invisible.

Deuxièmement, le blocage en 403 utilisé comme substitut de gestion : parce qu’un contenu n’est plus maintenu, ou parce qu’un robot coûte de la bande passante. Une 403 n’est pas un outil de modération d’exploration, et Google le dit explicitement.

Le mot d’ordre : préciser, pas fermer

La bonne question n’est jamais « comment accéder à tout ? » mais « qui, précisément, doit accéder à quoi ? ». Une règle qui cible un chemin, une méthode HTTP et un niveau de privilège produit rarement des faux positifs. Une règle qui bloque un motif large en produit tous les jours.

FAQ sur l’erreur 403 Forbidden

À lire aussi : les autres erreurs navigateur traitées sur notre site

Ce guide fait partie de notre cluster consacré aux erreurs de navigateur et de serveur. Si votre message n’est pas un 403 Forbidden, orientez-vous vers le guide correspondant :

• L’erreur ERR_CACHE_MISS : quand le navigateur ne retrouve pas une ressource en cache.
• L’erreur ERR_SSL_PROTOCOL_ERROR : quand le tunnel sécurisé ne se négocie pas.
• L’ERR_CONNECTION_REFUSED : quand le serveur refuse la connexion elle-même.
• L’ERR_CONNECTION_RESET : quand la connexion est coupée en cours de route.
• L’ERR_CONNECTION_TIMED_OUT : quand la réponse n’arrive jamais.
• L’ERR_INTERNET_DISCONNECTED : quand la coupure vient de votre poste.
• Le DNS_PROBE_STARTED : quand la résolution de nom bloque tout.
• L’erreur 526 : quand le certificat d’origine invalide bloque le CDN.
• Le pare-feu : le guide complet pour comprendre ce qui filtre vos requêtes.
• L’ERR_QUIC_PROTOCOL_ERROR : quand HTTP/3 échoue là où HTTP/2 passe.
• L’ERR_EMPTY_RESPONSE : quand le serveur ferme la connexion sans rien dire.
• Le SSL handshake failed : quand la poignée de main TLS n’aboutit pas.

Sources utiles et références vérifiées

• RFC 9110, HTTP Semantics, section 15.5.4 « 403 Forbidden » : rfc-editor.org/rfc/rfc9110.html
• MDN, 403 Forbidden (français) : developer.mozilla.org/fr/…/Status/403
• MDN, 401 Unauthorized (français) : developer.mozilla.org/fr/…/Status/401
• MDN, 404 Not Found (français) : developer.mozilla.org/fr/…/Status/404
• MDN, liste des codes de statut HTTP : developer.mozilla.org/fr/…/Reference/Status
• Documentation Apache, mod_authz_core (Require all denied) : httpd.apache.org/docs/2.4/mod/mod_authz_core.html
• Documentation Apache, mod_autoindex (Options -Indexes) : httpd.apache.org/docs/2.4/mod/mod_autoindex.html
• Documentation Apache, contrôle d’accès : httpd.apache.org/docs/2.4/howto/access.html
• Documentation Nginx, ngx_http_access_module (allow / deny) : nginx.org/en/docs/http/ngx_http_access_module.html
• Documentation Cloudflare, pare-feu applicatif web (WAF) : developers.cloudflare.com/waf
• Documentation Cloudflare, dépannage des erreurs 403 : developers.cloudflare.com/support/troubleshooting/http-status-codes
• Documentation WordPress, durcissement et permissions : developer.wordpress.org/advanced-administration/security/hardening
• Documentation WordPress, modifier les permissions de fichiers : wordpress.org/documentation/article/changing-file-permissions
• Google Search Console, rapport Indexation des pages : support.google.com/webmasters/answer/7440203
• Google Search Central, erreurs HTTP et réseau en exploration : developers.google.com/search/docs/crawling-indexing/http-network-errors
• Wikipédia, HTTP 403 (français) : fr.wikipedia.org/wiki/HTTP_403

Conclusion

L’erreur 403 Forbidden est mal lue parce qu’elle est mal nommée dans l’esprit collectif. Elle ne dit pas « page introuvable », elle ne dit pas « site en panne », elle ne dit pas « votre navigateur a un problème ». Elle dit : le serveur a compris, et il refuse. Tant que cette distinction n’est pas posée, tous les correctifs se ressemblent et aucun ne fonctionne.

Pour un visiteur, l’ordre d’attaque reste simple : recharger, tester en navigation privée, vider les cookies du seul domaine concerné, couper le VPN, changer de réseau. Cinq gestes, cinq minutes. Si l’erreur survit à tout cela sur deux réseaux différents, elle ne vient pas de vous.

Pour un éditeur, la vraie question est ailleurs. Quand plusieurs visiteurs voient la même 403 sur la même page, le coupable n’est ni le navigateur ni l’utilisateur : c’est une règle. Une permission héritée d’une migration, un .htaccess régénéré de travers, un plugin de sécurité trop large, une règle WAF jamais revue, un fichier index oublié. Ces causes se corrigent en une ligne. Elles se diagnostiquent en lisant les logs, pas en empilant des solutions.

Un dernier point de méthode, et c’est celui qui fait gagner le plus de temps : notez le code de statut, l’URL exacte, l’heure et le message affiché avant de modifier quoi que ce soit. Un signalement qui contient ces quatre éléments se résout en quelques minutes. Sans eux, il se transforme en échange de messages stérile avec l’hébergeur, l’agence ou le prestataire.

Note de transparence éditoriale

Ce guide s’appuie sur trois types de sources, et nous préférons le dire clairement.

• Documentation technique officielle : la RFC 9110 pour la définition normative du code 403, la documentation MDN pour la lecture comparative des statuts HTTP, la documentation Apache et Nginx pour les directives d’autorisation, la documentation Cloudflare pour les règles WAF, la documentation WordPress pour les permissions de fichiers, et l’aide Google Search Console pour l’impact sur l’exploration et l’indexation. Toutes les références figurent dans la section « Sources utiles » et sont vérifiables en un clic.
• Tests et cas réels : les cinq situations de la section « Retours du terrain » proviennent de tests et d’audits menés sur des sites WordPress, une infrastructure derrière CDN, un hébergement mutualisé ayant subi une migration, une API interne et un site dont l’exploration a été perturbée par un filtrage d’user-agent. Les libellés de menus et de directives correspondent aux versions récentes des outils cités.
• Limites : la configuration d’un serveur web dépend fortement de l’hébergeur et de la version en place. Les valeurs de permissions indiquées sont des repères courants, pas des obligations universelles. La répartition du tableau de verdict reflète nos observations, pas une mesure statistique sur un échantillon représentatif. Enfin, les interfaces des consoles CDN et des CMS évoluent : les noms de menus peuvent différer selon la version.

Divulgation d’intérêt : CritiquePlus monétise des prestations d’accompagnement auprès d’éditeurs d’outils numériques (tests, visibilité SEO, audit produit). Aucun éditeur n’est intervenu dans la rédaction de ce guide, et aucun lien commercial ne conditionne les correctifs recommandés. Les recommandations sont établies à partir de la documentation officielle citée et de nos propres reproductions de cas.