Pourquoi connecter Codex à WordPress — et comment le faire sans exposer ses identifiants

Publier un article dans WordPress mobilise peu de réflexion, mais impose une série d’opérations répétitives : rechercher les doublons, téléverser l’image, remplir son texte alternatif, sélectionner les taxonomies, créer le brouillon et contrôler les métadonnées.

Faire exécuter ces tâches par Codex libère du temps pour ce qui exige réellement un jugement humain : l’angle éditorial, la qualité du contenu, le maillage, l’intention de recherche et la décision de publier.

L’intérêt n’est donc pas de « mettre de l’IA dans WordPress ». Il est de transformer une procédure manuelle et irrégulière en workflow reproductible :

• mêmes contrôles avant chaque création ;
• mêmes règles de taxonomie ;
• brouillon par défaut ;
• vérification systématique après écriture ;
• intervention humaine réservée aux décisions éditoriales.

Mais cette automatisation ouvre un accès direct au CMS. Une mauvaise configuration peut exposer un identifiant, créer des contenus en double ou accorder à l’agent des permissions disproportionnées.

La méthode décrite ici repose donc sur quatre principes :

• utiliser Codex dans un environnement local capable d’accéder aux outils Windows ;
• s’authentifier avec un mot de passe d’application WordPress révocable ;
• conserver le secret dans le Gestionnaire d’informations d’identification Windows ;
• créer uniquement des brouillons, sauf instruction explicite de publication.

Pourquoi l’environnement local est indispensable

Une conversation web ordinaire ne dispose pas automatiquement d’un accès au coffre d’identifiants de l’ordinateur. Elle peut produire du contenu ou expliquer une procédure, mais elle ne peut pas nécessairement récupérer un secret Windows puis appeler WordPress avec celui-ci.

Il faut utiliser une surface locale de Codex — application Windows, CLI ou environnement local connecté — disposant des outils nécessaires et des autorisations strictement encadrées.

OpenAI indique que les surfaces locales de Codex peuvent agir sur les fichiers et les outils de la machine, dans les limites du bac à sable et des permissions configurées. (Documentation OpenAI sur Codex)

Cette distinction est déterminante : le modèle ne « connaît » pas le mot de passe. L’environnement local le récupère temporairement pour exécuter une opération autorisée.

Ce que Codex peut prendre en charge dans WordPress

Une intégration correctement configurée permet d’exécuter le workflow suivant :

1. rechercher un article existant par titre ou par slug ;
2. détecter un doublon probable ;
3. récupérer les catégories et les tags disponibles ;
4. téléverser une image ;
5. enregistrer son texte alternatif ;
6. créer l’article avec le statut draft ;
7. associer l’image mise en avant ;
8. affecter des taxonomies existantes ;
9. renseigner les métadonnées SEO accessibles ;
10. relire l’article par l’API pour contrôler le résultat.

L’API REST native de WordPress expose des ressources pour les articles, les médias, les utilisateurs et les taxonomies. Elle accepte notamment le titre, le contenu, le statut, l’image mise en avant, les catégories et les tags. (Référence officielle des articles, référence officielle des médias)

Le navigateur devient alors un outil de contrôle visuel ou de secours, pas le canal principal de production.

Créer un compte WordPress dédié

Utiliser directement un compte administrateur est simple, mais injustifiable.

Un administrateur peut modifier les réglages du site, installer des extensions, gérer les utilisateurs et provoquer des dégâts sans rapport avec la production éditoriale. Donner ce rôle à une automatisation supprime une barrière de sécurité uniquement pour gagner quelques minutes de configuration.

Il faut créer un compte dédié possédant seulement les capacités nécessaires, par exemple :

• modifier des articles ;
• téléverser des fichiers ;
• créer des brouillons ;
• éventuellement publier, si le workflow l’exige réellement.

WordPress distingue les rôles des capacités effectives. La configuration doit être guidée par les opérations autorisées, pas par le nom pratique d’un rôle. (Documentation WordPress sur les rôles et capacités)

Si Codex doit uniquement produire des brouillons, la capacité de publication est inutile. La conserver « au cas où » augmente l’impact potentiel d’une erreur ou d’une instruction malveillante.

Générer un mot de passe d’application WordPress

WordPress intègre les mots de passe d’application depuis la version 5.6. Ils permettent à un outil externe de s’authentifier auprès de l’API REST sans utiliser le mot de passe principal du compte.

Dans l’administration WordPress :

1. ouvrir le profil du compte dédié ;
2. accéder à la section des mots de passe d’application ;
3. créer un mot de passe avec un nom explicite, par exemple Automatisation éditoriale locale ;
4. copier immédiatement la valeur générée ;
5. conserver la possibilité de la révoquer indépendamment du compte.

Les identifiants peuvent être transmis à l’API avec une authentification Basic, à condition d’utiliser HTTPS. WordPress recommande les mots de passe d’application pour les requêtes REST externes. (Documentation officielle sur l’authentification REST)

Le mot de passe d’application ne doit jamais apparaître :

• dans le fichier AGENTS.md ;
• dans un script versionné ;
• dans un fichier .env ajouté au dépôt ;
• dans une commande conservée dans l’historique ;
• dans une conversation ;
• dans les journaux d’exécution.

Un mot de passe d’application reste un secret. Son caractère spécialisé ou révocable ne le rend pas inoffensif.

Stocker le secret dans le coffre Windows

Sous Windows, le Gestionnaire d’informations d’identification fournit un emplacement plus adapté qu’un fichier texte.

Ouvrez :

Panneau de configuration → Gestionnaire d’informations d’identification → Informations d’identification Windows

Ajoutez une information d’identification générique avec des valeurs neutres de ce type :

Adresse Internet ou réseau : wordpress-api-exemple
Nom d’utilisateur : compte-automatisation
Mot de passe : mot de passe d’application WordPress

Le nom de la cible sert uniquement à retrouver l’entrée. Il peut figurer dans les instructions du projet. Le mot de passe doit rester dans le coffre et n’être chargé en mémoire qu’au moment de l’appel API.

La séparation correcte est la suivante :

• AGENTS.md indique où trouver le secret ;
• le coffre Windows contient le secret ;
• l’outil local l’utilise temporairement ;
• aucune sortie ne révèle sa valeur.

Encadrer Codex avec un fichier AGENTS.md

Un fichier AGENTS.md transmet les règles permanentes du projet à Codex. Il doit contenir les contraintes opérationnelles, jamais les identifiants secrets.

Exemple anonymisé :

# Gestion WordPress

- Site public : https://example.com
- Administration : https://example.com/wp-admin/
- Utiliser l’API REST WordPress en priorité.
- Compte API : compte-automatisation.
- Identifiants stockés dans le coffre Windows sous la cible wordpress-api-exemple.
- Ne jamais afficher, journaliser ou enregistrer le secret.
- Créer un brouillon par défaut.
- Ne publier publiquement que sur instruction explicite.
- Utiliser uniquement les catégories et tags existants.
- Ne jamais créer automatiquement une taxonomie.
- Interrompre la création en cas de doublon plausible.

Ce fichier ne constitue pas une protection technique. Il fixe une politique de fonctionnement.

La sécurité réelle repose sur la combinaison de quatre éléments :

• un compte WordPress limité ;
• un secret conservé hors du projet ;
• un environnement local placé dans un bac à sable ;
• une validation après chaque opération d’écriture.

Tester l’authentification sans modifier le site

Le premier test doit être une requête en lecture seule :

GET https://example.com/wp-json/wp/v2/users/me?context=edit

Codex doit :

1. récupérer temporairement l’identifiant dans le coffre Windows ;
2. construire l’authentification sans afficher sa valeur ;
3. envoyer la requête via HTTPS ;
4. vérifier l’identité et les capacités retournées ;
5. supprimer les variables temporaires à la fin de l’opération.

Le contexte edit permet à un utilisateur authentifié d’obtenir les informations nécessaires à la validation de ses permissions, notamment ses capacités. (Référence WordPress des utilisateurs)

Le test est réussi uniquement si :

• le compte retourné est celui attendu ;
• les capacités nécessaires sont présentes ;
• aucune information sensible n’apparaît dans la sortie ;
• aucune donnée WordPress n’a été modifiée.

Un code HTTP 200 ne suffit pas. Le contenu de la réponse doit être vérifié.

Les principaux points d’accès de l’API

Pour un workflow éditorial standard, les routes utiles sont :

GET  /wp-json/wp/v2/posts
POST /wp-json/wp/v2/posts
GET  /wp-json/wp/v2/categories
GET  /wp-json/wp/v2/tags
POST /wp-json/wp/v2/media

La création d’un brouillon peut utiliser une charge utile de ce type :

{
  "title": "Titre de l’article",
  "content": "<p>Contenu de l’article</p>",
  "status": "draft",
  "featured_media": 123,
  "categories": [4],
  "tags": [12, 18]
}

Les catégories et les tags sont transmis sous forme d’identifiants. L’agent doit donc récupérer les taxonomies existantes avant de créer l’article.

Deviner un identifiant ou créer automatiquement un terme produit rapidement des doublons et une taxonomie incohérente.

Le workflow éditorial à imposer

Une automatisation fiable doit respecter une séquence contrôlable.

1. Rechercher les doublons

Interroger les articles existants avec le titre, le slug ou les principaux termes distinctifs.

Si plusieurs résultats proches apparaissent, la création doit être interrompue. Créer d’abord et nettoyer ensuite multiplie les brouillons concurrents et augmente le risque de publier la mauvaise version.

2. Résoudre les taxonomies

Récupérer les catégories et les tags existants, puis convertir les libellés retenus en identifiants WordPress.

Si un terme n’existe pas, l’agent doit le signaler. Il ne doit pas le créer sans autorisation explicite.

3. Téléverser l’image

Envoyer le fichier vers /wp-json/wp/v2/media, récupérer l’identifiant du média, puis enregistrer un texte alternatif descriptif.

Le champ alt_text est prévu par l’API REST des médias. Sa présence doit être confirmée par une relecture après modification.

4. Créer uniquement un brouillon

La requête de création doit imposer explicitement :

{
  "status": "draft"
}

Compter sur un comportement implicite est fragile. Une règle de sécurité doit apparaître dans la requête elle-même.

5. Relire le résultat

Après la création, interroger l’article à partir de son identifiant et vérifier :

• le statut ;
• le titre ;
• le contenu ;
• le slug ;
• l’image mise en avant ;
• les catégories ;
• les tags ;
• les métadonnées attendues.

Une réponse positive à la requête de création ne prouve pas que chaque champ a été accepté ou enregistré comme prévu.

Les métadonnées SEO constituent un cas séparé

Les champs d’un plugin SEO ne sont pas forcément accessibles en écriture dans l’API REST.

WordPress permet d’exposer des métadonnées avec le paramètre show_in_rest, ou d’ajouter des champs REST personnalisés avec leurs propres fonctions de lecture et d’écriture. Sans cette configuration, une métadonnée peut exister dans la base tout en restant inaccessible à l’agent. (Documentation WordPress sur les métadonnées REST)

Avant d’automatiser le titre SEO ou la méta-description, il faut examiner le schéma REST du site et effectuer un test sur un brouillon.

Si les champs ne sont pas modifiables, trois options existent :

1. configurer proprement leur exposition dans l’API ;
2. développer un endpoint WordPress limité à ces champs ;
3. compléter exceptionnellement les métadonnées dans l’interface d’administration.

L’agent ne doit jamais annoncer que les métadonnées sont enregistrées sans les avoir relues.

Le bac à sable local peut bloquer l’accès au coffre

Même exécuté localement, Codex peut fonctionner dans un bac à sable qui limite l’accès aux ressources du système. Le coffre Windows peut alors être invisible.

La mauvaise réponse consiste à autoriser sans limite l’exécution de commandes système. Cela transforme un blocage précis en permission générale.

Il faut plutôt :

• limiter l’autorisation à l’opération WordPress concernée ;
• contrôler le domaine réseau accessible ;
• autoriser uniquement l’outil chargé de lire l’entrée nécessaire ;
• empêcher l’affichage des valeurs récupérées ;
• conserver une validation humaine pour la publication publique.

OpenAI décrit ce fonctionnement comme une combinaison de bac à sable, de règles et d’approbations pour les opérations qui dépassent l’espace de travail autorisé. (Présentation de la sécurité de Codex)

Les erreurs qui annulent le bénéfice de l’automatisation

Cette architecture perd son intérêt si elle reproduit les mauvaises pratiques habituelles.

À arrêter immédiatement :

• utiliser un compte administrateur permanent ;
• transmettre le mot de passe principal du compte WordPress ;
• stocker un secret dans AGENTS.md ;
• afficher la commande d’authentification complète ;
• laisser l’agent créer librement catégories et tags ;
• publier automatiquement dès la première requête ;
• ignorer la détection des doublons ;
• considérer une réponse API positive comme une validation complète ;
• prétendre avoir enregistré des champs SEO non relus.

Le principal risque n’est pas que l’API échoue. C’est qu’elle réussisse avec une configuration trop permissive.

La configuration minimale acceptable

L’automatisation peut être considérée comme opérationnelle lorsque les critères suivants sont remplis :

• le compte WordPress est dédié et limité ;
• le mot de passe d’application est stocké dans le coffre Windows ;
• aucun secret n’est présent dans le projet ou les journaux ;
• l’authentification a été validée en lecture seule ;
• les articles sont créés en brouillon ;
• les doublons sont recherchés avant création ;
• seules les taxonomies existantes sont utilisées ;
• les médias et leurs textes alternatifs sont relus ;
• les champs SEO sont contrôlés séparément ;
• la publication publique exige une instruction explicite.

Le bénéfice n’est pas de supprimer quelques clics dans WordPress. Il est d’obtenir une chaîne de production éditoriale contrôlée, reproductible et vérifiable — sans transformer l’agent en administrateur incontrôlé du site.