Erreur 405 Method Not Allowed : signification et solutions

L’erreur 405 (code HTTP 405, « Method Not Allowed ») veut dire que le serveur a bien reçu ta requête et connaît la méthode utilisée, mais que l’adresse visée n’accepte pas cette méthode. Exemple typique : un formulaire envoie ses données en POST vers une URL qui n’accepte que GET. Ce n’est pas une panne du site, c’est un refus ciblé, et il se corrige côté serveur.

Visiteur ou propriétaire du site, les vérifications ne sont pas les mêmes : les deux cas sont traités ci-dessous.

Que signifie le code HTTP 405 ?

L’erreur 405 désigne la réponse d’un serveur qui reconnaît la méthode HTTP employée mais refuse de l’appliquer à la ressource demandée. C’est la définition de la RFC 9110, section 15.5.6, la norme qui décrit HTTP : publiée en juin 2022, elle remplace notamment la RFC 7231.

Une méthode HTTP désigne le mot placé en tête de chaque requête pour dire au serveur ce que l’on veut faire : GET pour lire une page, POST pour envoyer des données (un formulaire par exemple), DELETE pour supprimer. La RFC 9110 en définit 8 : GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS et TRACE. Seules GET et HEAD sont obligatoires pour tout serveur généraliste, toutes les autres sont facultatives. Un serveur a donc le droit de refuser POST ou DELETE sur une adresse donnée : c’est exactement ce que signale la 405.

La norme ajoute une obligation : le serveur doit joindre à sa réponse 405 un en-tête Allow. L’en-tête Allow désigne la ligne de la réponse qui liste les méthodes que la ressource accepte réellement (MDN Web Docs). Une réponse conforme ressemble à ceci :

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Ici, le serveur dit : « cette adresse se lit, elle ne reçoit pas de données ». La page MDN consacrée au code 405 précise aussi que des permissions incorrectes sur des fichiers ou des dossiers du serveur peuvent provoquer une 405 alors que la requête aurait dû réussir.

« 405 Method Not Allowed », « 405 Not Allowed » : les messages que tu peux voir

Le même code s’affiche sous plusieurs formes selon le logiciel qui répond :

• 405 Method Not Allowed : le libellé officiel de la norme (« 405 error » ou « status code 405 » dans les outils en anglais).
• 405 Not Allowed : la page par défaut de Nginx, écrite en dur dans son code source. On l’obtient par exemple en envoyant un POST vers une page HTML statique servie par Nginx.
• XML-RPC server accepts POST requests only. : le message de WordPress quand on ouvre /xmlrpc.php dans un navigateur.
• net::ERR_ABORTED 405 (Method Not Allowed) : la forme que peut prendre l’erreur dans la console de Chrome (voir la FAQ).

Tu es visiteur : que faire face à une erreur 405 ?

L’erreur vient de la configuration du site, pas de ton ordinateur ni de ta connexion. Tu ne peux pas la corriger toi-même, mais tu peux vérifier trois choses :

1. L’adresse. Si tu as ouvert directement un lien prévu pour recevoir un formulaire (un favori, une adresse copiée après un envoi), ton navigateur envoie un GET là où le serveur attend un POST. Sur WordPress, ouvrir /xmlrpc.php ou /wp-comments-post.php dans le navigateur renvoie toujours une 405 : c’est voulu.
2. Le parcours. Reviens sur la page du formulaire, recharge-la, puis renvoie-le depuis cette page.
3. Le signalement. Si l’erreur persiste, préviens le propriétaire du site en indiquant l’adresse de la page, l’heure et l’action faite (formulaire, paiement, connexion).

Tu gères le site : trouver la requête refusée

Avant de toucher à quoi que ce soit, identifie la requête exacte qui reçoit la 405.

1. Ouvre les outils de développement de Chrome : F12 ou Ctrl + Maj + I sous Windows et Linux, Cmd + Option + I sur Mac (documentation Chrome).
2. Va dans le panneau Network (Réseau), puis refais l’action qui échoue.
3. Clique sur la ligne marquée 405 et note l’adresse exacte, la méthode envoyée (GET, POST, PUT…) et, dans les en-têtes de réponse, la ligne Allow si elle est présente.

Tu peux aussi tester depuis un terminal : curl -i -X POST https://ton-site.fr/contact/. L’option -X choisit la méthode, -i affiche les en-têtes de la réponse. L’écart entre la méthode envoyée et la liste de Allow te dit quoi corriger.

Attention : Allow est obligatoire selon la norme, mais tous les serveurs ne l’envoient pas. Nginx, par exemple, renvoie sa page « 405 Not Allowed » sans cet en-tête. Dans ce cas, la méthode attendue se lit dans le code du formulaire, la documentation de l’API ou la configuration du serveur.

Les causes réelles d’une erreur 405

Un formulaire envoyé en POST vers une URL qui n’accepte que GET

L’attribut action du formulaire pointe vers une adresse qui ne sait pas traiter des données envoyées : une page HTML statique, ou une URL qui a changé après une refonte. Sur Nginx, c’est écrit dans le module qui sert les fichiers statiques : toute méthode autre que GET, HEAD ou POST reçoit une 405, et un POST vers un fichier existant aussi. Un formulaire de contact posé sur un site purement statique, sans script ni service pour recevoir l’envoi, tombe exactement dans ce cas.

La correction : faire pointer action vers un script ou un service qui traite réellement le POST. Si le formulaire s’envoie sans erreur mais qu’aucun e-mail n’arrive, c’est un autre problème, traité dans notre guide sur le formulaire de contact qui n’envoie rien.

Une règle de serveur Nginx ou Apache

Une 405 peut aussi être voulue par la configuration du serveur, puis oubliée.

• Nginx : la documentation officielle donne elle-même l’exemple if ($request_method = POST) { return 405; }. Cherche ce type de ligne dans la configuration du site. La directive limit_except, elle, restreint les méthodes avec des règles d’accès (allow, deny) : une méthode refusée de cette façon reçoit une 403, pas une 405.
• Apache : le module mod_allowmethods, disponible depuis Apache 2.3 et classé « expérimental », limite les méthodes avec une ligne comme AllowMethods GET POST OPTIONS ; les autres reçoivent une 405. Il se règle dans la configuration du serveur, pas dans le .htaccess. Les blocs <Limit> et <LimitExcept>, utilisables dans le .htaccess, appliquent des règles d’accès (Require) : ils produisent un refus d’accès ou une demande d’identification, pas une 405.

Sur un hébergement mutualisé, tu n’as pas la main sur cette configuration : c’est au support de l’hébergeur de vérifier.

Une API REST appelée avec la mauvaise méthode

Dans une API REST, chaque adresse (endpoint) accepte des méthodes précises : en général GET pour lire, POST pour créer, PUT pour remplacer, DELETE pour supprimer. Un POST sur une ressource qui n’accepte que GET produit une 405 : c’est l’exemple que donne la documentation de Cloudflare sur l’erreur 405. Vérifie la méthode attendue dans la documentation de l’API, puis le code qui l’appelle.

Un pare-feu ou une extension de sécurité

Cloudflare indique ne pas générer lui-même d’erreur 405 : elles viennent du serveur d’origine. Quand ses fonctions de sécurité bloquent une requête, le code est 403 dans la plupart des cas, ou 429 pour la limitation de débit (actions des règles Cloudflare). Seule exception : une règle personnalisée avec l’action Block peut renvoyer n’importe quel code entre 400 et 499, 403 par défaut (règles personnalisées Cloudflare). Si quelqu’un y a choisi 405, passe en revue ces règles.

Pour une extension de sécurité WordPress ou un pare-feu d’hébergeur, désactive-le quelques minutes et refais la requête. Si la 405 disparaît, ajuste la règle sur l’adresse concernée au lieu de laisser la protection coupée. Si tu obtiens une 403 et non une 405, c’est un autre diagnostic (voir la comparaison plus bas).

WordPress : quand la 405 est normale

Dans le cœur de WordPress, la 405 apparaît dans quelques cas précis, dont ces deux fichiers :

• /xmlrpc.php appelé autrement qu’en POST répond 405, avec l’en-tête Allow: POST et le message « XML-RPC server accepts POST requests only. » (code source).
• /wp-comments-post.php, qui reçoit les commentaires, fait la même chose (code source).

L’API REST (/wp-json/), elle, répond 404 avec le code rest_no_route quand aucune route ne correspond à la fois à l’adresse et à la méthode, et non 405 (code source). Une 405 sur une page ou un formulaire WordPress se cherche donc d’abord du côté du serveur, d’un pare-feu, d’une extension ou du thème. Si tu as restreint l’API REST, notre article sur l’API REST de WordPress explique comment la durcir sans casser le site.

Une redirection qui transforme un POST en GET

Pour les redirections 301 et 302, la RFC 9110 autorise le navigateur, pour des raisons historiques, à transformer un POST en GET. Si l’adresse d’arrivée n’accepte que POST, elle répond 405. Deux situations typiques : un formulaire qui envoie vers http:// alors que le site redirige vers https://, ou vers une adresse sans barre oblique finale que le serveur redirige vers la version avec barre.

La correction : viser directement l’adresse finale. Si la redirection doit rester, utilise une 307 (temporaire), qui interdit de changer la méthode, ou une 308 (définitive), que la norme propose quand ce changement n’est pas souhaité. La RFC précise que le code 308, créé en juin 2014, peut ne pas être reconnu partout.

Corriger l’erreur 405 étape par étape

1. Identifie la requête refusée (adresse, méthode, Allow) et compare-la à ce que l’adresse doit accepter.
2. Corrige au bon endroit, selon le tableau ci-dessous.
3. Purge les caches. La RFC 9110 classe la 405 parmi les réponses qu’un cache peut conserver même sans consigne explicite : après ta correction, vide le cache de ton extension et de ton CDN.
4. Reteste avec curl ou le panneau Network.

Erreur 405, 403 ou 501 : quelle différence ?

La RFC 9110 trace la frontière dans sa section 9.1 : un serveur qui reçoit une méthode qu’il ne reconnaît pas ou n’implémente pas devrait répondre 501 ; s’il la reconnaît et l’implémente mais ne l’autorise pas sur cette ressource, il devrait répondre 405.

Pour le détail des deux autres codes, voir nos articles sur l’erreur 403 Forbidden et sur l’erreur 501 Not Implemented.

FAQ