« La réponse n’est pas une réponse JSON valide » à l’enregistrement d’un article ? Ce message vient de l’API REST de WordPress : l’éditeur a interrogé le serveur et a reçu autre chose que la réponse attendue. Dans la quasi-totalité des cas, la cause est l’une de ces trois-là : une adresse de site incohérente, des permaliens cassés, ou une extension de sécurité qui bloque l’API. Trente secondes de diagnostic suffisent à savoir laquelle.
D’où vient ce message
L’éditeur de blocs ne recharge pas la page quand vous enregistrez. Il envoie discrètement votre contenu au serveur via l’API REST et attend en retour un objet JSON, un format de données structuré. Tant que la réponse est du JSON valide, tout se passe sans que vous voyiez quoi que ce soit.
Le message apparaît quand le serveur renvoie autre chose : une page d’erreur en HTML, une redirection, un avertissement PHP, une page de blocage d’un pare-feu, ou tout simplement rien. L’éditeur tente de lire cela comme du JSON, échoue, et vous signale l’échec sans pouvoir en expliquer la cause.
Retenez donc ceci : ce n’est pas une erreur de contenu, et votre article n’est pas en cause. C’est un problème de communication entre l’éditeur et le serveur. Le même message peut d’ailleurs apparaître au téléversement d’une image ou à la publication d’un produit.
Le diagnostic en trente secondes
Avant de toucher à quoi que ce soit, allez dans Outils > Santé du site > État. WordPress y exécute un test dédié à l’API REST. Deux cas de figure :
- Le test signale que l’API REST rencontre une erreur inattendue. Le message affiché contient souvent le code HTTP reçu, qui oriente immédiatement : un 403 pointe vers un blocage de sécurité, un 404 vers un problème de permaliens, un 301 vers une incohérence d’adresse.
- Le test passe sans erreur. Le problème est alors plus probablement local : conflit d’extension sur une page précise, image trop lourde, ou coupure réseau pendant l’enregistrement.
Vous pouvez aussi ouvrir directement votre-site.fr/wp-json/ dans le navigateur. Vous devez y voir un bloc de données brutes. Une page d’erreur, une redirection ou un écran blanc confirment que l’API est inaccessible.
Cause 1 — Une adresse de site incohérente
C’est la première chose à vérifier, en particulier après un passage en HTTPS ou une migration. Dans Réglages > Général, les deux champs « Adresse web de WordPress » et « Adresse web du site » doivent être rigoureusement identiques en protocole et en préfixe.
Un site en https://www.exemple.fr dont un champ indique encore http://exemple.fr produit exactement ce symptôme : l’éditeur appelle une adresse, le serveur redirige vers une autre, et la redirection n’est pas du JSON. Corrigez, enregistrez, videz les caches, et retestez.
Cause 2 — Des permaliens ou un .htaccess cassés
L’API REST s’appuie sur la réécriture d’URL. Si les règles sont corrompues, l’adresse /wp-json/ retourne une page 404 au lieu des données attendues.
La correction est immédiate : allez dans Réglages > Permaliens et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress régénère ses règles de réécriture. Si le fichier .htaccess n’est pas modifiable, un message vous le dira ; ajustez alors ses droits en écriture par FTP, ou remplacez son contenu par le bloc standard fourni par WordPress dans le même écran.
Cette manipulation est sans risque et résout à elle seule une bonne part des cas. C’est celle par laquelle commencer si le test de Santé du site renvoie un code 404.
Cause 3 — L’API REST est bloquée
Beaucoup d’extensions de sécurité proposent de désactiver l’API REST ou d’en restreindre l’accès aux utilisateurs connectés, au nom d’un durcissement du site. L’intention est bonne, l’effet de bord est celui-ci : l’éditeur ne peut plus enregistrer.
Regardez du côté de votre extension de sécurité, de son pare-feu applicatif, et de toute option intitulée « désactiver l’API REST » ou « bloquer wp-json ». Désactivez temporairement l’extension pour confirmer le diagnostic ; si l’enregistrement redevient possible, réactivez-la et cherchez la règle précise plutôt que de vous en passer.
Le blocage peut aussi venir du serveur lui-même, via un module de sécurité comme ModSecurity, ou d’un service de protection placé devant le site. Dans ce cas, seul l’hébergeur peut consulter les règles déclenchées et poser une exception. Donnez-lui l’heure exacte d’une tentative d’enregistrement : il retrouvera la ligne correspondante dans ses journaux.
Cause 4 — Un certificat SSL incomplet
Un certificat expiré, mal installé, ou dont la chaîne de certification est incomplète empêche l’appel interne d’aboutir, même si le navigateur affiche le cadenas. Le symptôme typique : le site s’affiche normalement mais l’éditeur refuse d’enregistrer.
Testez votre certificat avec un vérificateur SSL en ligne. S’il signale une chaîne incomplète, c’est à l’hébergeur d’y remédier. Vérifiez au passage que tout le site est bien servi en HTTPS : un contenu mixte, avec des ressources encore appelées en HTTP, provoque des symptômes voisins.
Cause 5 — Un conflit d’extension ou de thème
Si le message n’apparaît que sur certains contenus, ou depuis l’installation d’une extension précise, le test standard s’applique : désactivez toutes les extensions, vérifiez que l’enregistrement fonctionne, puis réactivez-les par moitiés successives. La méthode complète, y compris sans accès à l’administration, est décrite dans notre guide sur la désactivation d’une extension en FTP.
Une variante mérite d’être connue : un avertissement PHP émis par une extension ou par le functions.php du thème s’ajoute à la réponse du serveur et la rend illisible. Le JSON est bien là, mais précédé de texte parasite. Activez le journal de débogage et regardez si des avertissements sont émis au moment de l’enregistrement.
Cas particulier : le message apparaît au téléversement d’un média
Quand l’erreur ne survient qu’en ajoutant une image, la piste change complètement. Vérifiez la taille maximale de téléversement autorisée, affichée en bas de la médiathèque : un fichier plus lourd est rejeté par le serveur, qui répond une page d’erreur au lieu du JSON attendu.
Vérifiez aussi les droits en écriture du dossier wp-content/uploads, et l’espace disque restant sur votre hébergement. Un disque plein produit ce message sans le moindre indice explicite.
La solution de contournement, et ses limites
On lit souvent qu’il suffit de repasser à l’éditeur classique, qui n’utilise pas l’API REST pour enregistrer. C’est exact, et cela peut dépanner quand une publication est urgente.
Mais ce n’est pas une correction. L’API REST sert bien au-delà de l’éditeur : applications mobiles, extensions, intégrations, certains réglages du site. La laisser hors service revient à masquer un problème qui ressortira ailleurs. Utilisez ce contournement comme un délai, pas comme une réponse.
Questions fréquentes
Mon article est-il perdu ?
Pas nécessairement. Avant toute manipulation, sélectionnez tout le contenu dans l’éditeur et copiez-le, ou basculez en éditeur de code pour récupérer le HTML brut. WordPress conserve par ailleurs des sauvegardes automatiques : si vous parvenez à rouvrir l’article plus tard, une version récente est souvent proposée à la restauration dans le panneau des révisions.
Faut-il désactiver l’API REST pour sécuriser mon site ?
Non, c’est un mauvais réflexe hérité d’anciennes recommandations. L’API REST fait partie intégrante de WordPress et l’éditeur de blocs en dépend. La désactiver casse des fonctions attendues sans gain de sécurité réel. Si votre préoccupation est l’exposition des noms d’utilisateurs, restreignez précisément les points d’accès concernés plutôt que de couper l’ensemble.
Pourquoi l’erreur n’apparaît-elle que sur certaines pages ?
Parce que la requête envoyée dépend du contenu. Une page très longue, riche en blocs ou contenant du code peut dépasser une limite du serveur — nombre de champs autorisés, taille de requête, délai d’exécution — quand une page courte passe sans encombre. C’est aussi le comportement typique d’un pare-feu applicatif, qui ne se déclenche que sur certains motifs, par exemple du code dans le contenu.
Le problème peut-il venir de mon navigateur ?
C’est rare mais possible. Une extension de navigateur, notamment un bloqueur de publicités ou de traqueurs, peut interférer avec les requêtes de l’éditeur. Testez en navigation privée, où les extensions sont désactivées par défaut, ou depuis un autre navigateur. Si l’enregistrement fonctionne là, vous avez isolé la cause en une minute.
Comment vérifier que l’API REST fonctionne de nouveau ?
Deux vérifications complémentaires. Ouvrez votre-site.fr/wp-json/ : un bloc de données brutes doit s’afficher. Puis relancez le test dans Outils > Santé du site, qui doit passer au vert. Terminez par un test réel : enregistrez un brouillon et téléversez une image, puisque ces deux opérations empruntent des chemins différents.
Ce message peut-il annoncer une panne plus grave ?
Il arrive qu’il précède une erreur critique, lorsqu’une extension défaillante commence par perturber l’API avant de faire tomber le site. Si le message s’accompagne de lenteurs, de pages blanches ponctuelles ou d’avertissements PHP, ne vous contentez pas d’un contournement : activez le journal de débogage et cherchez la cause de fond.