Erreur 405 WordPress : corriger Method Not Allowed

Pour corriger une erreur 405 WordPress, vérifiez d’abord la méthode HTTP envoyée et l’en-tête Allow de la réponse, puis contrôlez la route REST, les permaliens, le pare feu et les extensions de sécurité. Le code 405, ou Method Not Allowed, signifie que le serveur comprend la requête, mais refuse la méthode utilisée pour cette URL. Dans la majorité des cas, il faut remplacer la méthode, corriger l’URL de la route ou retirer une règle qui bloque POST, PUT ou DELETE. Ne désactivez pas toute la sécurité avant d’avoir identifié la couche responsable.

Cette erreur apparaît souvent quand l’éditeur de blocs ne publie plus, quand WooCommerce refuse une mise à jour, quand un formulaire ne s’envoie pas ou quand une application utilise la REST API WordPress. Si le code reçu est plutôt 401, consultez notre guide sur l’erreur 401 de la REST API WordPress. Voici une méthode de diagnostic reproductible, du test le plus rapide à la correction côté serveur.

Que signifie une erreur 405 WordPress

Une erreur 405 WordPress est une réponse HTTP indiquant que la ressource existe, mais qu’elle n’accepte pas la méthode demandée. Une URL peut autoriser GET pour lire une ressource, POST pour la créer, puis PUT ou PATCH pour la modifier. Si le client envoie POST au mauvais endpoint, le serveur peut répondre 405. Ce n’est donc pas la même panne qu’une erreur 404, qui indique une route introuvable, ni qu’une erreur 403, qui concerne principalement l’autorisation.

La réponse devrait contenir l’en-tête Allow. Il donne les méthodes acceptées par la ressource. Cette information permet de distinguer une erreur de programmation d’un blocage Apache, Nginx, LiteSpeed, d’un WAF ou d’une extension WordPress. Le standard HTTP recommande cette indication, mais certains hébergeurs renvoient une page générique qui oblige à compléter l’analyse avec les journaux.

curl -i -X OPTIONS https://exemple.fr/wp-json/wp/v2/posts/123
curl -i -X GET https://exemple.fr/wp-json/wp/v2/posts/123

Commencez toujours par une copie de sauvegarde et un test sur une page de staging si la requête écrit des données. Une commande PUT ou DELETE mal construite peut modifier ou supprimer un contenu valide.

Identifier l’URL et la méthode qui déclenchent l’erreur

Le message affiché dans le navigateur est rarement assez précis. Ouvrez les outils de développement, puis l’onglet Réseau. Reproduisez l’erreur et relevez l’URL complète, la méthode, le code de statut, la redirection éventuelle et la réponse. Dans l’éditeur de blocs, une requête vers /wp-json/wp/v2/posts/ n’a pas le même rôle qu’une requête vers /wp-json/wp/v2/posts/123. Dans WooCommerce, la collection et la ressource produit individuelle n’acceptent pas toujours les mêmes verbes.

Comparez ensuite la requête qui fonctionne avec celle qui échoue. Un changement de domaine, de slash final, de protocole ou de chemin peut déclencher une redirection. Une redirection mal gérée transforme parfois un POST en GET et produit un 405 sur l’URL finale. Vérifiez aussi que votre client ne force pas Content-Type ou une méthode non prévue par l’endpoint.

# Afficher les redirections et les en-têtes
curl -sS -D - -o /dev/null -L https://exemple.fr/wp-json/wp/v2/posts/123

# Tester explicitement un endpoint de lecture
curl -i -H 'Accept: application/json'   https://exemple.fr/wp-json/wp/v2/posts/123

Si l’erreur se produit uniquement dans l’administration, reproduisez-la après avoir vidé le cache du navigateur. Si elle apparaît dans curl, Postman et l’éditeur, cherchez plutôt côté serveur ou route WordPress. Cette séparation évite de modifier le thème pour une erreur qui vient du WAF.

Corriger une erreur 405 de la REST API WordPress

La REST API WordPress utilise des routes et des méthodes précises. Pour lire une collection, GET est généralement adapté. Pour créer une ressource, POST est courant. Pour modifier une ressource existante, l’endpoint doit généralement contenir son identifiant et accepter POST, PUT ou PATCH selon l’implémentation. Pour supprimer, DELETE est réservé aux routes qui l’autorisent. Une requête envoyée à la collection alors qu’elle vise un élément est une cause classique de 405.

Commencez par inspecter la route racine et le document des routes. Si /wp-json/ répond correctement mais que la route métier renvoie 405, l’API globale fonctionne. Le problème concerne alors la méthode, la route personnalisée ou une couche de protection. Pour distinguer une route introuvable, voyez aussi notre guide sur l’erreur 404 de la REST API WordPress. Une route déclarée par une extension peut limiter ses méthodes avec methods et filtrer l’accès avec permission_callback.

# Vérifier que l’API répond
curl -i https://exemple.fr/wp-json/

# Inspecter la route et les méthodes annoncées
curl -sS https://exemple.fr/wp-json/ | python3 -m json.tool
curl -i -X OPTIONS https://exemple.fr/wp-json/wp/v2/posts/123

Pour une écriture, utilisez une authentification adaptée. Dans WordPress, les mots de passe d’application sont conçus pour les intégrations serveur à serveur. Le nonce de cookie convient au contexte d’un utilisateur connecté dans le navigateur, mais ne remplace pas une authentification pour une application externe. Une erreur d’authentification renvoie plutôt 401 ou 403, toutefois une extension de sécurité peut masquer la cause derrière un 405.

curl -i -X POST   -u 'utilisateur:xxxx xxxx xxxx xxxx xxxx xxxx'   -H 'Content-Type: application/json'   -d '{"title":"Test REST","status":"draft"}'   https://exemple.fr/wp-json/wp/v2/posts

Si la route est personnalisée, vérifiez qu’elle a un permission_callback explicite et que le tableau methods correspond au client. N’ajoutez pas toutes les méthodes pour faire disparaître l’erreur. Cela agrandit la surface d’attaque et peut exposer une opération d’écriture.

register_rest_route('mon-plugin/v1', '/rapport', [
    'methods'  => WP_REST_Server::CREATABLE,
    'callback' => 'mon_plugin_creer_rapport',
    'permission_callback' => function () {
        return current_user_can('edit_posts');
    },
]);

Réparer les permaliens et les réécritures

Une structure de permaliens incohérente peut envoyer la requête vers le mauvais contrôleur. Dans l’administration, ouvrez Réglages, puis Permaliens, et enregistrez à nouveau la structure actuelle. Cette action régénère les règles de réécriture WordPress. Elle ne supprime normalement pas les contenus, mais faites une sauvegarde avant toute modification de configuration.

Testez ensuite l’URL avec et sans slash final, puis examinez le statut de chaque étape avec curl -I. Si le POST reçoit une réponse 301 ou 302 avant le 405, corrigez l’URL appelée par le formulaire ou l’application. Une API ne devrait pas dépendre d’une redirection de domaine pour une requête d’écriture.

curl -sS -o /dev/null -D -   -X POST https://exemple.fr/wp-json/wp/v2/posts

# Comparer le chemin canonique
curl -sS -o /dev/null -D -   -X POST https://www.exemple.fr/wp-json/wp/v2/posts/

Ne remplacez pas le fichier .htaccess par un modèle trouvé au hasard. Sur une installation Apache classique, les règles WordPress doivent laisser passer les requêtes vers index.php. Une règle LimitExcept, une directive de réécriture ou une protection ajoutée par l’hébergeur peut toutefois bloquer un verbe précis. Comparez la configuration avec une sauvegarde saine.

Vérifier le WAF, le serveur et les extensions de sécurité

Quand la route et la méthode sont correctes, localisez le moment où le 405 est produit. Une réponse WordPress contient souvent des en-têtes et une structure JSON reconnaissables. Une page HTML signée par le proxy, LiteSpeed, Cloudflare ou un WAF indique que WordPress n’a peut être jamais reçu la requête. Consultez les journaux d’accès et d’erreur autour de l’heure exacte du test.

Les règles de durcissement bloquent parfois PUT, DELETE ou OPTIONS par principe. C’est risqué pour une REST API moderne, car certains clients les utilisent légitimement. Autorisez uniquement les méthodes nécessaires sur les chemins nécessaires. Sur un hébergement mutualisé, demandez au support de vérifier la règle ModSecurity avec l’URL, l’heure et l’identifiant de la requête, plutôt que de demander une désactivation globale.

# Vérifier les en-têtes d’une requête bloquée
curl -i -X PUT   -H 'Content-Type: application/json'   -d '{"title":"Test"}'   https://exemple.fr/wp-json/wp/v2/posts/123

# Comparer avec une lecture publique
curl -i https://exemple.fr/wp-json/wp/v2/posts/123

Désactivez temporairement une seule extension de sécurité ou de cache sur staging, puis rejouez le test. Si l’erreur disparaît, réactivez les extensions une par une. Cherchez les fonctions qui filtrent rest_pre_dispatch, rest_request_before_callbacks ou les méthodes HTTP. Pour le cas où le serveur refuse l’accès plutôt que la méthode, consultez le guide sur l’erreur 403 et les permissions REST. Un cache ne doit pas servir une ancienne réponse 405 à la place d’une réponse fraîche.

Diagnostiquer un formulaire, WooCommerce ou l’éditeur de blocs

Un formulaire frontend peut envoyer POST vers une URL qui n’accepte plus cette méthode après une migration. Contrôlez son attribut action, son champ caché de nonce et la route réellement appelée. Pour WooCommerce, distinguez l’API WooCommerce d’une route WordPress standard et vérifiez la version du client. Pour l’éditeur, une erreur persistante peut signaler un conflit de plugin, un nonce expiré, une URL WordPress incorrecte ou un WAF.

Le bon ordre de test est simple. Reconnectez la session, rechargez l’éditeur, testez /wp-json/, essayez la même route avec curl, puis activez le journal de debug sur un environnement de test. Si la réponse contient une erreur PHP ou du HTML avant le JSON, corrigez d’abord cette sortie parasite. Elle peut être affichée comme une erreur générique par JavaScript.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Après le diagnostic, désactivez le debug public et conservez seulement un journal protégé si nécessaire. Ne demandez jamais à un utilisateur de transmettre un mot de passe ou une clé d’API dans une capture d’écran. Masquez les cookies, les en-têtes Authorization et les mots de passe d’application.

Checklist finale pour éliminer l’erreur 405

Une correction fiable doit fonctionner depuis le navigateur et depuis un client HTTP, avec le même endpoint et la même méthode. Vérifiez les points suivants dans cet ordre :

  • l’URL ne redirige pas pendant une requête d’écriture;
  • la méthode apparaît dans l’en-tête Allow;
  • la route contient l’identifiant quand elle vise une ressource précise;
  • les permaliens et les règles de réécriture sont à jour;
  • l’authentification, le nonce et la capacité sont valides;
  • le WAF, le serveur et les extensions ne bloquent pas le verbe;
  • la réponse reste un JSON valide sans avertissement PHP;
  • les journaux ne montrent plus de 405 après purge ciblée du cache.

Si le problème persiste, fournissez à l’hébergeur l’URL, la méthode, l’heure UTC, le code de réponse, l’en-tête Allow et l’identifiant de corrélation. Cette fiche est beaucoup plus utile qu’un simple message disant que WordPress ne fonctionne plus.

FAQ sur l’erreur 405 WordPress

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

Une erreur 404 signifie que l’URL ou la route n’a pas été trouvée, tandis qu’une erreur 405 signifie que la ressource existe mais refuse la méthode HTTP utilisée. Contrôlez donc d’abord le verbe et l’en-tête Allow pour une 405.

Pourquoi l’éditeur WordPress affiche t il une erreur 405 à la publication ?

L’éditeur utilise la REST API pour enregistrer le contenu. Une méthode bloquée, un nonce expiré, un conflit d’extension, une redirection ou une règle WAF peut refuser la requête. Testez la route dans l’onglet Réseau puis avec curl.

Comment corriger une erreur 405 sur une route REST personnalisée ?

Vérifiez le tableau methods, l’URL de la route et le permission_callback. Faites correspondre le verbe du client à celui déclaré par register_rest_route, puis retestez avec une authentification adaptée.

Faut il désactiver le pare feu pour supprimer une erreur 405 ?

Non. Désactivez au maximum une règle ciblée sur un environnement de test afin d’identifier la cause, puis autorisez uniquement la méthode et le chemin nécessaires. Une désactivation globale crée un risque inutile.

Que faire si l’en-tête Allow est absent ?

Inspectez les journaux et les en-têtes du proxy, car un WAF ou l’hébergeur peut générer la réponse avant WordPress. Comparez la réponse avec un endpoint public et demandez au support d’identifier la règle qui produit le 405.

Sources vérifiées

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.