TL;DRL'erreur 405 signifie que l'adresse existe, mais qu'elle refuse la méthode HTTP utilisée, par exemple un POST envoyé vers une page qui n'accepte que GET. Pour la corriger, lisez l'en-tête Allow de la réponse, qui liste les méthodes acceptées, puis alignez la requête ou la configuration de la route.

Que signifie l'erreur 405 ?#

L'erreur 405 Method Not Allowed indique que la page existe, mais qu'elle n'accepte pas la façon dont vous l'interrogez. Chaque requête HTTP porte une méthode : GET pour lire une page, POST pour envoyer un formulaire, PUT, PATCH ou DELETE pour modifier une ressource dans une API. Si l'adresse est bonne mais la méthode refusée, le serveur répond 405.

La RFC 9110, qui définit la sémantique HTTP, précise deux choses importantes. D'abord, la méthode est connue du serveur : c'est la ressource visée qui ne la prend pas en charge. Ensuite, le serveur doit renvoyer un en-tête Allow qui liste les méthodes acceptées. Cet en-tête est votre meilleur indice pour corriger.

Ce code appartient à la famille des erreurs 4xx. Retrouvez les autres codes sur notre page codes d'erreur HTTP.

Côté visiteur : les gestes utiles#

Pour un internaute, une 405 survient le plus souvent autour d'un formulaire :

  • Ne rechargez pas une page de résultat : après l'envoi d'un formulaire, l'actualisation ou le bouton « Précédent » peuvent rejouer la requête dans de mauvaises conditions. Revenez à la page du formulaire et recommencez.
  • N'utilisez pas un favori pointant vers une page de traitement (par exemple une adresse de validation de commande) : elle n'est faite que pour recevoir un POST.
  • Videz le cache du navigateur si l'erreur persiste sur une page qui fonctionnait avant.
  • Prévenez le site en indiquant la page et l'action effectuée : la correction est presque toujours de son côté.

Côté propriétaire : diagnostiquer avec curl#

La première étape consiste à rejouer la requête et à lire la réponse complète. L'option -X de curl choisit la méthode, -i affiche les en-têtes.

curl -i -X POST https://exemple.fr/contact
curl -i -X OPTIONS https://exemple.fr/api/articles
curl -I https://exemple.fr/contact

Dans la réponse, cherchez :

  • la ligne Allow:, qui liste les méthodes acceptées par cette adresse ;
  • l'en-tête Server: ou la page d'erreur, qui indique qui répond (nginx, Apache, IIS, votre application, un pare-feu applicatif) ;
  • une éventuelle redirection (301 ou 302) juste avant la 405.

Ce dernier point piège beaucoup d'API. Quand un POST reçoit une redirection 301 ou 302, par exemple pour ajouter un slash final ou passer en HTTPS, la plupart des clients rejouent la requête en GET. La nouvelle adresse, qui n'accepte que POST, répond alors 405. Les codes 307 et 308 conservent la méthode d'origine : utilisez-les pour rediriger des requêtes autres que GET, ou mieux, appelez directement l'URL finale.

curl -i -L -X POST http://exemple.fr/api/commandes

Avec -L, curl suit les redirections et affiche chaque étape : vous voyez précisément où la méthode change.

Arbre de décision : de la requête reçue au code 404, 501, 405 ou 200
Schéma simplifié : le serveur vérifie d'abord la méthode, puis l'adresse, puis si cette adresse accepte la méthode.

405, 403, 404 ou 501 : ne pas confondre#

CodeSensIndice typiquePiste de correction
403 ForbiddenLa ressource existe, l'accès est refuséDroits de fichiers, règle de pare-feu, denyRevoir les permissions ou la règle qui bloque
404 Not FoundAucune ressource à cette adresseFaute dans l'URL, route absenteCorriger le lien ou créer la route
405 Method Not AllowedLa ressource existe mais refuse cette méthodeEn-tête Allow présentUtiliser une méthode listée ou l'autoriser sur la route
501 Not ImplementedLe serveur ne connaît pas du tout la méthodeMéthode inconnue pour toutes les ressourcesChanger de méthode ou de serveur

La frontière entre 405 et 501 est nette dans la RFC : 405 concerne une ressource précise, 501 concerne le serveur entier. Pour les deux autres codes, voir nos guides sur l'erreur 403 et l'erreur 404.

Cause 1 : un formulaire POST envoyé vers une page statique#

C'est la cause la plus fréquente sur les sites vitrines. Un formulaire HTML envoie ses données en POST vers une adresse qui correspond à un fichier statique (.html), sans script pour les traiter. nginx refuse alors la requête avec une page « 405 Not Allowed ».

La correction consiste à faire pointer l'attribut action du formulaire vers un script capable de traiter l'envoi (PHP, une route de votre framework, un service de formulaires), et non vers la page HTML elle-même.

<form method="post" action="/contact/envoyer">

Le même problème apparaît après une migration : un ancien site PHP devient un site statique, mais les formulaires gardent leur ancienne cible.

Cause 2 : une API REST appelée avec la mauvaise méthode#

Une API associe chaque action à une méthode. Appeler PUT quand seule PATCH est prévue, ou envoyer un GET sur une adresse de création, donne une 405. Consultez la documentation de l'API, puis vérifiez avec une requête OPTIONS si le serveur la gère : la réponse liste souvent les méthodes autorisées. Vérifiez aussi que votre client HTTP n'est pas redirigé (voir plus haut).

Cause 3 : WebDAV sur IIS#

Sur un serveur Windows avec IIS, le module WebDAV Publishing peut intercepter les requêtes PUT et DELETE destinées à votre application et répondre 405. Microsoft documente cette cause et recommande de retirer les modules et gestionnaires WebDAV dans le web.config si vous ne les utilisez pas :

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

Microsoft cite aussi les requêtes POST envoyées au gestionnaire de fichiers statiques : c'est l'équivalent IIS de la cause 1.

Cause 4 : une règle du serveur web#

Dans nginx, la directive limit_except restreint les méthodes d'un bloc location. Attention : combinée à deny all, elle renvoie une 403, pas une 405. Autoriser GET autorise aussi HEAD.

location /admin/ {
    limit_except GET POST {
        deny all;
    }
}

Si vous voulez une vraie 405 conforme, avec l'en-tête Allow exigé par la RFC, écrivez-la explicitement :

location /api/ {
    if ($request_method !~ ^(GET|HEAD|POST)$) {
        add_header Allow "GET, HEAD, POST" always;
        return 405;
    }
    # ...
}

Testez toujours avant de recharger : sudo nginx -t && sudo systemctl reload nginx. Pour l'organisation générale de vos blocs, voir aussi nos optimisations nginx.

Sous Apache, l'équivalent passe par mod_rewrite. Un code hors de la plage 300-399 dans le drapeau R ignore la cible et arrête la réécriture :

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$
RewriteRule ^ - [R=405,L]

Cherchez aussi les blocs <Limit> ou <LimitExcept> hérités dans vos fichiers .htaccess : ils peuvent bloquer une méthode que votre application attend.

Cause 5 : un pare-feu applicatif (mod_security)#

Un pare-feu applicatif comme mod_security, avec le jeu de règles OWASP CRS, filtre les méthodes autorisées. Par défaut, la liste est courte (GET, HEAD, POST, OPTIONS) et une API qui reçoit PUT ou DELETE est bloquée. Selon la configuration, le code renvoyé est une 403 ou une 405.

Le journal d'audit indique la règle déclenchée. Si l'API est légitime, élargissez la variable tx.allowed_methods dans la configuration CRS pour ce site plutôt que de désactiver le pare-feu.

sudo grep -i "not allowed by policy" /var/log/apache2/modsec_audit.log | tail -n 5

Un code 405 ou 403 qui n'apparaît que pour certaines méthodes, alors que votre code applicatif les accepte, vient très souvent d'une couche intermédiaire : pare-feu, proxy, CDN. Comparez la réponse obtenue en appelant directement le serveur et celle obtenue à travers le proxy.

Cause 6 : les routes de votre framework#

Dans Symfony, l'option methods d'une route limite les méthodes acceptées. Une requête sur la bonne adresse avec une autre méthode lève une exception MethodNotAllowedHttpException, convertie en réponse 405.

#[Route('/contact', name: 'contact', methods: ['GET', 'POST'])]
public function contact(Request $request): Response

Pour vérifier la configuration réelle d'une route :

php bin/console debug:router contact

La colonne Method indique les méthodes autorisées. ANY signifie qu'aucune restriction n'est posée.

Dans Laravel, la méthode est fixée par la déclaration elle-même : Route::post(), Route::put(), Route::match(). Les formulaires HTML ne savent envoyer que GET et POST : pour un PUT ou un DELETE, Laravel attend un champ caché ajouté par la directive Blade @method('PUT'). Sans lui, la requête arrive en POST et la route répond 405. La commande php artisan route:list affiche les méthodes de chaque route.

Cas WordPress : API REST et XML-RPC#

L'API REST de WordPress se comporte un peu différemment : une méthode non prévue sur une route renvoie en général une erreur rest_no_route avec un code 404, et non une 405. Si vous voyez une vraie 405 sur /wp-json/, elle vient plus probablement du serveur web ou d'un pare-feu qui bloque PUT ou DELETE.

WordPress documente une solution pour ces environnements : envoyer la requête en POST avec le paramètre _method ou l'en-tête X-HTTP-Method-Override.

curl -i -X POST -H "X-HTTP-Method-Override: DELETE" \
  -u utilisateur:mot-de-passe-application \
  https://exemple.fr/wp-json/wp/v2/posts/42

La documentation précise de n'utiliser ce mécanisme qu'avec des requêtes POST, jamais avec GET, pour éviter une mise en cache incorrecte. Autre cas courant : ouvrir /xmlrpc.php dans un navigateur affiche « XML-RPC server accepts POST requests only. ». C'est le comportement normal, pas une panne.

Et pour le SEO ?#

Googlebot explore les pages en GET. Une page publique qui répond 405 à un GET est traitée comme les autres erreurs 4xx : elle n'est pas indexée. Vérifiez donc qu'aucune règle de méthode ne s'applique par erreur à vos pages publiques, en particulier après la mise en place d'un pare-feu ou d'une nouvelle configuration serveur.

Besoin d'aide ?#

Une 405 se corrige vite une fois la couche fautive identifiée : en-tête Allow, redirection qui change la méthode, règle serveur ou route mal déclarée. Si vous ne trouvez pas d'où elle vient, contactez-nous avec la commande curl qui reproduit l'erreur. Websource héberge un grand nombre de sites et accompagne ses clients dès la commande : nos offres d'hébergement web incluent la configuration du serveur adaptée à votre application, avec migration offerte en offres Premium et Advanced, et sur devis en Standard.

Questions fréquentes#

Quelle est la différence entre une erreur 405 et une erreur 404 ?#

Avec une 404, rien n'existe à cette adresse. Avec une 405, l'adresse existe mais refuse la méthode utilisée, par exemple un POST là où seul GET est accepté. La 405 s'accompagne d'un en-tête Allow qui donne les méthodes possibles.

Pourquoi mon formulaire de contact renvoie-t-il une erreur 405 ?#

Le plus souvent, l'attribut action du formulaire pointe vers une page HTML statique qui ne peut pas traiter un POST. Faites-le pointer vers un script ou une route qui gère l'envoi. Vérifiez aussi qu'aucune redirection ne transforme le POST en GET.

Comment connaître les méthodes acceptées par une URL ?#

Lancez curl -i -X OPTIONS suivi de l'URL, ou rejouez la requête refusée avec curl -i. L'en-tête Allow de la réponse liste les méthodes acceptées. La RFC 9110 rend cet en-tête obligatoire dans une réponse 405.

Une erreur 405 peut-elle nuire au référencement ?#

Oui si elle touche des pages publiques en GET, car Googlebot les explore avec cette méthode et n'indexe pas les URL en erreur 4xx. Une 405 limitée à des adresses de traitement de formulaire ou d'API n'a pas d'effet sur le référencement.

Faut-il répondre 405 ou 501 à une méthode inconnue ?#

La RFC 9110 réserve 501 aux méthodes que le serveur ne reconnaît pour aucune ressource. Si la méthode est connue mais non prise en charge par la ressource visée, la bonne réponse est 405 avec un en-tête Allow.

Article publié le 14/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.