Un formulaire qui refuse de s’envoyer, une erreur 405 qui s’affiche
Un visiteur remplit un formulaire de contact, clique sur “envoyer”, et voit apparaître : 405 Method Not Allowed. Ou pire, un appel API qui fonctionnait la veille échoue soudainement avec ce même code. Le réflexe est de penser que le site est cassé de fond en comble. Ce n’est pas le cas.
L’erreur 405 signifie une chose précise : le serveur a bien reçu la requête, il a compris l’adresse demandée, mais il refuse la méthode HTTP utilisée pour y accéder. Concrètement, quelqu’un (un navigateur, un script, une intégration) envoie une requête POST (pour soumettre des données) sur une URL qui n’accepte que du GET (pour afficher une page), ou l’inverse. C’est une erreur de communication entre client et serveur, pas une panne générale.
La bonne nouvelle : dans l’immense majorité des cas, la cause est identifiable en quelques minutes et la correction ne touche ni au contenu ni au design du site. On reste sur de la configuration.
Pourquoi ça arrive
L’erreur 405 a un nombre limité de sources récurrentes :
- Un formulaire mal configuré : l’attribut
actiondu formulaire pointe vers une URL qui n’accepte pas les requêtes POST (souvent après une migration ou un changement de permaliens). - Un cache trop agressif : un plugin de cache ou un CDN sert une version statique de la page au lieu de laisser passer la requête dynamique, et une page en cache ne sait traiter que du GET.
- Un pare-feu applicatif (WAF) ou un plugin de sécurité qui bloque certaines méthodes HTTP sur des routes précises, souvent après un durcissement de sécurité.
- Une règle serveur trop restrictive dans le fichier
.htaccess(Apache) ou dans un bloclocation(Nginx) qui limite explicitement les méthodes autorisées. - Un appel API mal formé : le développeur (ou l’IA qui a généré le code) appelle un endpoint avec la mauvaise méthode, ou l’URL de l’API a changé sans que l’intégration soit mise à jour.
- Une redirection qui transforme un POST en GET : certaines redirections 301/302 mal configurées perdent la méthode d’origine en cours de route.
- Les permaliens WordPress mal réglés, qui cassent le routage vers
/wp-json/et l’API REST.
Ce dernier point est fréquent sur les sites WordPress qui utilisent des formulaires dynamiques, du e-commerce ou des intégrations tierces (paiement, newsletter, CRM).
1. Reproduire l’erreur et identifier le contexte exact
Avant toute correction, il faut savoir où l’erreur se produit : sur une soumission de formulaire, sur un appel API, sur une page d’administration, sur un checkout ? Ouvre les outils de développement du navigateur (F12), onglet Réseau, et reproduis l’action. Tu verras la requête en rouge avec le code 405, l’URL exacte appelée et la méthode utilisée. Cette information oriente tout le reste du diagnostic.
Si l’erreur touche un formulaire de contact, la piste la plus probable est décrite dans notre article sur le formulaire de contact qui n’envoie rien, ou, si tu utilises Contact Form 7, dans ce guide dédié.
2. Vérifier l’URL et la méthode envoyée
Une cause banale mais fréquente : le formulaire pointe vers une URL avec une ancre (#) au lieu de la vraie action, ou vers une page qui a été supprimée ou renommée. Vérifie le code source du formulaire (attribut action) et assure-toi que l’URL cible existe bien et accepte la méthode utilisée. Si le formulaire a été généré par une IA (Lovable, Bolt, v0) sans vérification humaine derrière, ce type d’incohérence entre front et back est courant — un cas typique où le brief créatif change tout par rapport au simple prompt.
3. Vider les caches, plugin et CDN
Un cache statique qui sert une page HTML figée là où le serveur attend une requête dynamique est une source classique de 405, en particulier sur les pages de checkout WooCommerce ou les formulaires AJAX. Vide le cache du plugin (WP Rocket, LiteSpeed Cache, Perfmatters) et celui du CDN si tu en utilises un (Cloudflare notamment). Si tu es sous Cloudflare, vérifie aussi les règles de configuration DNS et de cache : une règle de cache trop large peut intercepter des routes qui ne devraient jamais être mises en cache.
4. Contrôler le pare-feu applicatif et les plugins de sécurité
Après un durcissement de sécurité (souvent recommandé, notamment après la faille wp2shell), certains plugins bloquent les méthodes HTTP sur des routes sensibles comme /wp-json/, /wp-admin/admin-ajax.php ou les endpoints de paiement. Désactive temporairement le plugin de sécurité (Wordfence, Sucuri, iThemes Security) pour confirmer ou infirmer cette piste. Si le 405 disparaît, il faut affiner la règle plutôt que désactiver la protection durablement — voir notre approche sur l’API REST WordPress et sa sécurisation.
5. Vérifier la configuration serveur (.htaccess ou Nginx)
Sur un serveur Apache, une directive <LimitExcept GET POST> mal placée dans le .htaccess peut bloquer certaines méthodes sur un répertoire entier. Ouvre le fichier via SSH ou FTP, cherche les blocs <Limit> ou <LimitExcept>, et vérifie qu’ils incluent bien les méthodes nécessaires (GET, POST, et parfois PUT/DELETE pour les API REST). Sur Nginx, le bloc équivalent est limit_except dans la configuration du site. Si tu n’as pas l’habitude de la ligne de commande, nos guides de connexion en SSH sur OVH, IONOS ou Plesk détaillent la marche à suivre selon ton hébergeur.
6. Vérifier les permaliens WordPress et le routage de l’API
Si l’erreur touche /wp-json/, le problème vient souvent des permaliens. Va dans Réglages > Permaliens, sans rien changer, clique sur “Enregistrer les modifications”. Cette action force WordPress à régénérer les règles de réécriture dans le .htaccess, ce qui corrige un grand nombre de blocages sur l’API REST et les routes dynamiques. Si le souci persiste après une migration d’hébergeur, consulte la checklist site inaccessible après changement d’hébergeur.
7. Vérifier le reverse proxy ou le CDN en amont
Si le site passe par Cloudflare ou un autre reverse proxy, certaines règles de pare-feu (WAF managé, règles de page) peuvent filtrer les méthodes HTTP avant même que la requête n’atteigne le serveur d’origine. Vérifie dans le tableau de bord Cloudflare les règles de sécurité actives sur le domaine et teste en les désactivant temporairement une par une.
Tableau récapitulatif
| Cause | Solution |
|---|---|
| URL du formulaire incorrecte ou obsolète | Corriger l’attribut action, vérifier que la page cible existe |
| Cache statique servant une page dynamique | Vider le cache plugin + CDN, exclure la route du cache |
| Plugin de sécurité / WAF trop restrictif | Ajuster la règle sur la route concernée, ne pas désactiver la sécurité durablement |
| Directive Apache/Nginx trop stricte | Corriger <LimitExcept> (Apache) ou limit_except (Nginx) |
| Permaliens WordPress cassés | Réenregistrer les permaliens sans modification |
| Appel API avec mauvaise méthode ou mauvaise URL | Vérifier la documentation de l’endpoint, corriger le code d’appel |
| Redirection qui transforme un POST en GET | Utiliser une redirection 307/308 qui préserve la méthode |
FAQ
La 405 vient-elle forcément de WordPress ?
Non. Cette erreur peut apparaître sur n’importe quel type de site ou d’application qui expose des routes HTTP : sites WordPress, applications Next.js, API tierces, plateformes e-commerce. WordPress est simplement un cas fréquent car il combine formulaires, API REST et plugins de cache/sécurité qui interagissent entre eux.
Pourquoi mon checkout WooCommerce renvoie une 405 ?
C’est souvent un cache trop agressif qui sert une page de paiement en statique, ou une règle de sécurité qui bloque le POST vers /checkout/. Consulte notre guide sur les erreurs WooCommerce courantes pour un diagnostic plus complet côté panier et paiement.
Une redirection peut-elle vraiment causer une 405 ?
Oui. Une redirection 301 ou 302 classique transforme automatiquement une requête POST en GET lors du nouveau saut, ce qui peut faire échouer une soumission de formulaire ou un appel API vers la mauvaise méthode. Si tu dois rediriger une route qui reçoit du POST, utilise une redirection 307 ou 308, qui préserve la méthode d’origine.
Faut-il désactiver mon plugin de sécurité pour corriger l'erreur ?
Seulement le temps du diagnostic. Une fois la règle en cause identifiée, il vaut mieux l’ajuster précisément (en excluant la route concernée) plutôt que de désactiver durablement une protection utile, surtout après un durcissement de sécurité récent.
L'erreur touche une API tierce que je ne contrôle pas, que faire ?
Vérifie d’abord la documentation officielle de l’API pour confirmer la méthode HTTP attendue sur l’endpoint appelé. Un changement de version d’API côté fournisseur peut rendre obsolète un appel qui fonctionnait auparavant. C’est fréquent avec les intégrations de paiement ou d’emailing, comme celles décrites dans notre guide sur Resend.
Quand passer la main à un pro
Si le diagnostic pointe vers une règle serveur, un WAF managé ou une intégration API qui dépasse la simple configuration WordPress, mieux vaut faire intervenir quelqu’un qui manipule ces couches au quotidien. Un mauvais ajustement de .htaccess ou de règle Nginx peut transformer une erreur 405 en page blanche complète — un scénario détaillé dans notre diagnostic page blanche toutes plateformes. Une agence en maintenance a l’avantage de connaître l’historique du site et d’éviter ces effets domino.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy