Accès API WordPress de Claude

Note technique documentant comment Claude accède à l’API REST de generatepress.inforweb.ch pour publier des articles automatiquement, et pourquoi cette configuration a été nécessaire.

Le problème initial

Le site utilise Solid Security Pro (rebranding de iThemes Security). Par défaut, l’authentification par mot de passe d’application — le mécanisme natif de WordPress permettant à un outil externe de publier via l’API REST sans exposer le mot de passe principal — était invisible sur le profil de l’administrateur.

Diagnostic effectué :

1. La section “Mots de passe d’application” n’apparaissait pas du tout sur wp-admin/profile.php pour le compte admin.
2. Le réglage Solid Security API Access → REST API (Default Access / Restricted Access) a été testé sans effet.
3. La désactivation complète du plugin faisait immédiatement réapparaître la fonctionnalité, confirmant que Solid Security en était bien responsable.
4. Cause identifiée : la double authentification (2FA), activée sur le compte administrateur, désactive automatiquement les mots de passe d’application pour ce compte. C’est un comportement de sécurité volontaire du plugin — un mot de passe d’application permettrait sinon de contourner la 2FA.

La solution retenue

Plutôt que de désactiver la 2FA ou le plugin sur le compte principal (ce qui aurait affaibli la protection de l’administrateur), un compte dédié a été créé :

• Utilisateur WordPress claudeia
• Un groupe Solid Security spécifique (“claudeia”) a été configuré avec l’accès à l’API REST activé pour ce groupe uniquement
• Un mot de passe d’application a été généré pour ce compte depuis son profil (Utilisateurs → Profil → Mots de passe d’application)

⚠️ Point de vigilance identifié : une vérification via l’API (/wp-json/wp/v2/users/me?context=edit) montre que le compte claudeia a le rôle Administrateur, avec les pleins droits (création/suppression d’utilisateurs, gestion des extensions, etc.), et non un rôle restreint (Auteur ou Éditeur) comme initialement recommandé. Le mot de passe d’application associé donne donc un accès complet au site. À réévaluer : soit rétrograder ce compte vers un rôle Auteur/Éditeur suffisant pour publier des articles, soit accepter ce niveau d’accès en connaissance de cause.

Le mot de passe d’application lui-même n’est jamais stocké en clair dans ce document, dans le projet, ni conservé par Claude au-delà de la session en cours où il est fourni.

Fonctionnement technique

• Authentification HTTP Basic Auth (identifiant + mot de passe d’application) sur l’API REST native de WordPress, exposée à https://generatepress.inforweb.ch/wp-json/wp/v2/
• Endpoints utilisés :
  • GET /wp-json/wp/v2/users/me — vérifier que l’authentification fonctionne
  • POST /wp-json/wp/v2/categories — créer une catégorie (ex. “Formation Claude”, “Claude Test IA”)
  • GET /wp-json/wp/v2/media?search=... — retrouver l’ID d’une image déjà présente dans la médiathèque
  • POST /wp-json/wp/v2/posts — créer un article (titre, contenu HTML, catégorie, image à la une, statut)
• Les fichiers .md locaux sont convertis en HTML via Pandoc avant envoi (le champ content de l’API REST attend du HTML, pas du Markdown)

Pour une prochaine session

1. Vérifier que le compte claudeia existe toujours et que son groupe Solid Security a bien l’accès REST API actif (Solid Security peut réinitialiser ce réglage lors d’une mise à jour)
2. Fournir à Claude, dans la conversation, l’identifiant claudeia et un mot de passe d’application valide (en générer un nouveau si besoin — les anciens restent valides tant qu’ils ne sont pas révoqués individuellement)
3. Convention retenue pour les articles de ce projet : toujours définir l’image à la une avec le média ID 46 (photos-03.jpg), sauf indication contraire