Mis à jour le 20 octobre 2026.
Si vous utilisez le plugin Semly, commencez par sa documentation de connexion. Le diagnostic ci-dessous concerne toujours l'API REST standard de WordPress ; un mot de passe d'application n'est pas requis par le mécanisme d'association du plugin Semly.
Cette procédure concerne un WordPress auto-hébergé utilisant l’API REST standard. Un connecteur particulier ou WordPress.com peut imposer d’autres modalités.
Identifier la requête concernée
Notez la méthode HTTP, l’URL sans secret, l’heure, le statut, le type de contenu et les champs code et message éventuels. Pour les articles standard, la route est /wp-json/wp/v2/posts. Une installation en sous-répertoire ou un type de contenu personnalisé peut modifier l’adresse.
Consultez l’index /wp-json/. La forme ?rest_route=/wp/v2/posts peut aider à diagnostiquer un problème de réécriture d’URL. Pouvoir lire une route ne prouve pas le droit d’y créer un article.
Examiner le statut avec le contexte
| Statut | Vérifications |
|---|---|
| 401 | Identifiants, méthode d’authentification, HTTPS et transmission de l’en-tête Authorization |
| 403 | Droits de l’utilisateur, extension de sécurité, pare-feu applicatif ou proxy |
| 404 | Adresse, méthode, route, sous-répertoire et identifiant d’article |
Le statut seul ne suffit pas. Une erreur rest_cannot_create ne prouve pas que l’authentification a réussi. Une réponse JSON peut également venir d’un intermédiaire ; rapprochez les résultats des journaux administrateur.
Vérifier l’authentification sans exposer les secrets
Pour un client externe compatible, utilisez sur HTTPS un mot de passe d’application associé au compte prévu. Ne copiez jamais un mot de passe principal ni la valeur d’Authorization dans les journaux ou un ticket. Vérifiez la transmission de l’en-tête sans enregistrer sa valeur.
Une lecture de /wp-json/wp/v2/users/me peut confirmer l’identité ; elle ne garantit pas le droit de créer ou de publier. L’authentification par cookies avec nonce constitue un autre mécanisme : ne mélangez pas ses exigences avec celles des mots de passe d’application.
Tester un brouillon
Sur votre propre site, préparez un POST vers https://example.com/wp-json/wp/v2/posts, avec authentification configurée dans le client et Content-Type: application/json :
{"title":"API test","content":"Test","status":"draft"}
Contrôlez l’identifiant retourné, le statut et la présence du brouillon dans l’administration. Si la création est incertaine, recherchez d’abord l’article avant de répéter le POST. Un brouillon enregistré et lisible est le critère de réussite ; publier exige des droits supplémentaires.
Transmettre un diagnostic exploitable
Envoyez au responsable l’heure, la méthode, l’URL et une réponse expurgée des secrets. Corrigez la cause confirmée. N’attribuez pas un rôle administrateur et ne désactivez pas globalement les protections uniquement pour faire passer le test.
