Erreur 405 Method Not Allowed : comprendre, diagnostiquer et corriger

405 method not allowed signifie que le serveur a bien trouvé la ressource demandée, mais refuse la méthode HTTP utilisée. En clair : l’URL existe, mais l’action envoyée ne colle pas. Un formulaire tente un POST sur une route prévue pour GET. Une API reçoit un PUT alors qu’elle n’accepte que PATCH. Un plugin WordPress bloque une requête REST. Le piège, c’est de corriger trop vite côté serveur alors que le problème vient parfois d’un formulaire, d’un appel JavaScript ou d’une route applicative mal déclarée. Je préfère une méthode simple : vérifier la requête, lire la réponse, isoler la couche fautive, puis seulement modifier la configuration.

Réponse rapide : que signifie 405 Method Not Allowed ?

HTTP 405 est un code d’erreur client de la famille 4xx. Le serveur comprend la requête. Il connaît la méthode envoyée. Mais la ressource ciblée ne la prend pas en charge. La définition de MDN sur le statut 405 le formule clairement : le serveur connaît la méthode, mais la ressource ne la supporte pas.

La nuance compte. Une 404 veut dire que la ressource n’est pas trouvée. Une 403 veut dire que l’accès est interdit. Une 501 veut dire que le serveur ne sait pas traiter cette méthode du tout. Une 405, elle, pointe plutôt vers un mauvais couple URL + méthode.

Exemple court :

POST /mentions-legales HTTP/1.1
Host: exemple.fr

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

Ici, la page existe. Mais elle n’attend pas de POST. L’en-tête Allow aide beaucoup, quand il est présent et correctement configuré. Bon, dans la vraie vie, il est parfois absent, incomplet ou contredit par un proxy. C’est pénible, mais c’est justement pour ça qu’on diagnostique par couches.

Pourquoi une erreur 405 apparaît sur un site ou une API ?

La mauvaise correction consiste à chercher « comment débloquer 405 sur Nginx » et à coller une règle trouvée au hasard. Mauvais réflexe. Une erreur 405 peut venir du navigateur, de l’application, du CMS, du serveur, d’un WAF ou d’un hébergeur. Même symptôme, causes très différentes.

Méthode HTTP incorrecte côté client, formulaire, JS ou outil API

Premier suspect : la requête elle-même. Un formulaire HTML envoie souvent GET ou POST. Une requête fetch() ou Axios peut envoyer PUT, PATCH, DELETE ou OPTIONS. Postman, curl et certains connecteurs no-code ajoutent aussi leur petite couche de surprise.

J’ai déjà vu une route accusée pendant une heure alors que le front envoyait un POST à cause d’un copier-coller de composant. Le résultat ? Une 405 parfaite, mais côté back tout était propre.

Route applicative qui n’accepte pas la méthode utilisée

Dans une application web, la route peut exister sans accepter toutes les méthodes. C’est normal. Une route GET /articles/42 affiche un article. Une route PATCH /articles/42 le modifie. Mélanger les deux doit produire une erreur, pas une acceptation silencieuse.

Sur Express, Laravel, Symfony, Django, Spring ou une API WordPress REST, vérifiez la déclaration de route. Pas seulement l’URL. La méthode aussi.

CMS, plugin ou thème qui intercepte mal une requête

WordPress, Drupal, Prestashop ou un autre CMS peuvent intercepter une requête avant votre code. Un plugin de sécurité, un formulaire, un cache agressif ou un thème qui surcharge un endpoint peut transformer une action valide en 405.

Sur WordPress, les suspects fréquents sont les formulaires, les endpoints REST, admin-ajax.php, les permaliens et les règles de réécriture. Franchement, désactiver tous les plugins en production pour « tester vite » est une mauvaise idée. Faites-le en staging ou ciblez le dernier changement connu.

Règle serveur Apache, Nginx, IIS, .htaccess ou proxy

Le serveur peut refuser certaines méthodes avant que l’application ne voie la requête. Apache peut le faire via .htaccess, <Limit>, <LimitExcept> ou mod_rewrite. Nginx via limit_except, une mauvaise directive location ou un proxy mal configuré. IIS via ses handlers ou ses verbes autorisés.

À ce niveau, le diagnostic doit être froid. Une règle serveur a souvent été ajoutée pour une bonne raison. La supprimer sans comprendre revient à réparer une porte bloquée en démontant la serrure.

WAF, firewall, CORS ou blocage de sécurité

Un WAF, un CDN ou un firewall applicatif peut bloquer PUT, DELETE, PATCH ou TRACE. C’est fréquent sur des environnements mutualisés ou des stacks exposées au public. CORS ajoute un autre piège : la requête OPTIONS de préflight peut échouer avant même la vraie requête.

Si l’erreur n’arrive que depuis le navigateur, mais pas depuis curl côté serveur, regardez CORS et les en-têtes. Si elle arrive partout, remontez vers la route, le proxy ou le serveur.

Permissions ou configuration d’hébergement

Des permissions serveur incorrectes peuvent aussi déclencher une 405, notamment quand le serveur ne peut pas traiter correctement une ressource ou un répertoire. MDN le mentionne. Ce n’est pas la cause la plus glamour, mais elle existe. Et oui, elle tombe souvent après une migration ou une restauration.

Diagnostic en 7 étapes avant de modifier la production

Voici la séquence que j’utiliserais sur un site client. Pas la plus spectaculaire. La plus sûre.

1. Reproduire précisément. Notez l’URL exacte, la méthode, le navigateur ou client API, l’utilisateur connecté ou non, et l’heure.
2. Inspecter la requête. Dans l’onglet Network, curl ou Postman, vérifiez la méthode réellement envoyée. Pas celle que vous pensez envoyer.
3. Lire la réponse. Regardez le statut, Allow, les redirections éventuelles, le corps de réponse et les en-têtes ajoutés par un proxy.
4. Comparer avec la route attendue. La ressource doit-elle accepter GET, POST, PUT, PATCH, DELETE ou OPTIONS ?
5. Contrôler les changements récents. Plugin, thème, déploiement, règle de cache, WAF, migration, changement de permaliens.
6. Lire les logs à l’heure exacte. Logs d’accès, logs d’erreur, logs applicatifs, logs proxy. L’heure exacte évite de lire du bruit.
7. Tester en staging. Avant rollback, modification .htaccess ou règle Nginx. Oui, même si la prod brûle un peu.

Le point qui fait gagner du temps : comparer deux requêtes. Une qui passe, une qui échoue. Même URL ? Même méthode ? Même cookie ? Même origine ? Même slash final ? Les détails bêtes font souvent la différence.

Corriger une erreur 405 sur WordPress ou un CMS

Sur WordPress, ne commencez pas par le serveur. Commencez par le dernier changement. Une mise à jour de plugin, une extension de sécurité, un formulaire, un cache ou une modification des permaliens explique plus d’incidents que les grandes théories Apache.

La correction propre ressemble à ça :

• créer une sauvegarde exploitable, pas juste « normalement on a une sauvegarde » ;
• reproduire en staging si le site a du trafic ou des formulaires critiques ;
• désactiver le dernier plugin concerné, surtout sécurité, cache, formulaire ou REST API ;
• réenregistrer les permaliens pour régénérer les règles de réécriture ;
• contrôler .htaccess côté Apache ou la configuration Nginx côté hébergeur ;
• tester l’endpoint REST ou le formulaire avec la méthode réellement attendue.

Pour l’API REST WordPress, une 405 sur un endpoint peut simplement indiquer que la route existe en lecture, mais pas en écriture. Exemple : GET fonctionne, POST échoue. Ce n’est pas forcément un bug. C’est parfois une permission, un nonce, une route non déclarée en écriture ou un plugin qui filtre les méthodes.

Mon avis : évitez les « snippets miracles » qui autorisent tout dans .htaccess. C’est une rustine dangereuse. Corrigez la route, le plugin ou la règle fautive. Le serveur ne doit pas devenir permissif pour masquer un mauvais routage.

Corriger une erreur 405 côté API ou application web

Côté API, l’erreur 405 est presque toujours une histoire de contrat. L’endpoint existe. La méthode envoyée n’est pas celle prévue. À ce stade, la bonne question n’est pas « comment supprimer l’erreur ? », mais « quelle méthode cette route doit-elle accepter ? ».

Quelques cas classiques :

• POST /users/42 alors que la mise à jour attend PATCH /users/42 ;
• DELETE bloqué par le framework faute de route déclarée ;
• OPTIONS non géré, donc préflight CORS en échec ;
• formulaire HTML qui ne sait envoyer que GET ou POST, avec une méthode simulée mal interprétée ;
• requête JSON envoyée avec un Content-Type incohérent, puis interceptée par un middleware.

Dans une architecture rendue côté serveur, le traitement ne s’arrête pas au navigateur. Si votre stack mélange rendu, routes API et middleware, le rappel sur le server-side rendering peut aider à replacer où la requête est réellement traitée. Ce n’est pas un détail académique. C’est souvent la frontière entre un bug front et un bug serveur.

Testez ensuite par endpoint. Une matrice simple suffit : route, méthode attendue, méthode refusée, statut obtenu, en-tête Allow, test automatisé associé. Pas besoin d’un tableur de 80 colonnes. Juste de quoi éviter la régression au prochain déploiement.

Corriger une erreur 405 côté serveur, proxy ou sécurité

Là, on entre dans la zone où il faut ralentir. Une 405 produite par Apache, Nginx, IIS, un reverse proxy ou un WAF peut être légitime. Les méthodes PUT, DELETE, PATCH et surtout TRACE ne doivent pas être ouvertes partout.

Apache : cherchez les règles <Limit>, <LimitExcept>, RewriteCond et RewriteRule. Un .htaccess hérité peut refuser des méthodes sans que l’application ne soit en cause. Nginx : inspectez location, limit_except, try_files, proxy_pass et les redirections. IIS : regardez les handlers et WebDAV, qui est un grand classique des méthodes bloquées après publication.

Sur CDN ou WAF, cherchez les règles qui filtrent par verbe HTTP. Beaucoup de politiques bloquent PUT et DELETE par défaut. C’est souvent sain. Le correctif doit être ciblé sur l’endpoint utile, pas global.

Les logs serveur donnent aussi un signal de performance et de disponibilité. Une vague de 405 sur un endpoint critique peut dégrader l’expérience avant même que le SEO ne voie quoi que ce soit. Si vous corrélez les erreurs avec des temps de réponse serveur, la notion de Time to First Byte donne un bon repère pour comprendre ce que l’utilisateur subit vraiment.

Règle simple : n’ouvrez jamais une méthode HTTP globalement pour corriger un seul endpoint. Corrigez l’endpoint, la route ou l’exception de sécurité. Le reste doit rester fermé.

Tableau de diagnostic : symptôme, cause probable, action sûre

Quand l’incident arrive, ce tableau évite de partir dans tous les sens.

Le niveau de risque ne mesure pas la gravité business. Il mesure le risque de casser autre chose en corrigeant. Modifier une route applicative testée est rarement dangereux. Modifier un WAF en production à 17h45, beaucoup plus.

Prévenir les erreurs 405 en production

Une erreur 405 isolée n’est pas dramatique. Une erreur 405 récurrente sur un formulaire de contact, une API de panier ou une route d’authentification, là, c’est un vrai problème d’exploitation.

Prévention minimale :

• documenter les méthodes attendues par route, surtout sur les endpoints publics ;
• ajouter des smoke tests après déploiement sur les routes critiques ;
• tester les préflights CORS si le front et l’API ne partagent pas la même origine ;
• monitorer les 4xx par endpoint, pas seulement le total global ;
• garder une procédure de rollback claire pour plugins, règles serveur et WAF ;
• refuser TRACE et éviter d’exposer PUT ou DELETE hors endpoints justifiés ;
• renvoyer des messages API utiles en interne, sans exposer de détail sensible côté public.

Ce dernier point est sous-estimé. Une 405 peut être techniquement correcte et opérationnellement nulle si personne ne comprend ce qui l’a déclenchée. Loguez la méthode, la route, l’origine et l’identifiant de requête. Pas les secrets, pas les tokens. Juste assez pour diagnostiquer sans fouiller à l’aveugle.

FAQ courte

Si l’erreur revient, traitez-la comme un signal d’architecture

Une 405 qui apparaît une fois après un mauvais appel API, ça se corrige. Une 405 qui revient à chaque déploiement dit autre chose : vos routes, votre CMS, votre proxy ou votre WAF ne sont pas alignés. Et là, le sujet dépasse le ticket technique.

La bonne suite consiste à auditer le parcours complet de la requête : navigateur, CDN, serveur, application, CMS, logs, tests de non-régression. GreenCodeLab peut accompagner ce travail via son approche de conseil technique, notamment quand l’incident touche le SEO technique, la performance ou la stabilité d’un site en production.

Dernier rappel, volontairement sec : ne corrigez pas une 405 en rendant le serveur plus permissif. Corrigez le contrat entre la ressource et la méthode. C’est moins spectaculaire. C’est beaucoup plus propre.