Comment réétiqueter d’anciens articles en plusieurs langues dans WordPress avec l’IA de Codex

Il y a peu, je me suis retrouvé face à un nouveau défi : comment ajouter une nouvelle étiquette — dans mon cas, « science-fiction » — à tous les articles, aussi bien en espagnol que dans les autres langues. 

Autrement dit, près de 3 000 articles qu’il fallait :

• Analyser pour voir lesquels correspondaient vraiment à l’étiquette.
• Ajouter l’étiquette dans la langue correspondante à chacun sans supprimer les autres étiquettes.
• Vérifier que tout s’était bien passé.

Créer l’étiquette dans chaque langue n’avait rien de compliqué avec le développement que j’ai mis en place. Le problème, c’était d’étiqueter uniquement les anciens articles qui devaient vraiment l’avoir.

On pourrait le faire à la main, bien sûr, mais après avoir passé le contenu en revue, je me suis retrouvé avec une liste de 12 articles en espagnol. Cela signifie que, comme le site est traduit en dix langues, je devais étiqueter au total 120 articles.

Et rechercher chaque entrée dans sa langue, l’ouvrir et ajouter l’étiquette 120 fois, l’une après l’autre, très peu pour moi, franchement.

Je me suis donc dit que c’était une tâche plutôt adaptée à Codex.

En plus, je voulais utiliser ce cas assez simple comme base pour quelque chose de beaucoup plus général : appliquer automatiquement des modifications à de nombreux articles, sans laisser l’agent faire des changements tout seul et n’importe comment.

C’est précisément ce que je t’explique dans ce tutoriel.

Objectif

Simple : ajouter une étiquette précise à une liste fermée d’articles WordPress.

En incluant la traduction correspondante de cette étiquette pour chaque version linguistique de l’article, avec Polylang, qui est le plugin multilingue que j’utilise.

Et nous n’allons pas faire ça à l’arrache, mais avec quelques précautions :

• Nous travaillerons à partir d’une liste fermée d’articles.
• Nous vérifierons d’abord ce que Codex va modifier.
• Nous ne créerons pas automatiquement de nouvelles étiquettes.
• Nous conserverons toutes les étiquettes que chaque article possède déjà.
• Nous ferons une simulation avant d’écrire quoi que ce soit.
• Nous vérifierons de nouveau WordPress ensuite pour contrôler le résultat.

Ton cas n’a pas besoin d’être exactement identique au mien. Il suffit que tu veuilles modifier quelque chose sur une série précise d’articles WordPress qui te prendrait pas mal de temps à la main.

De mon côté, j’utilise Codex, mais tu peux suivre exactement le même processus si tu préfères Claude Code ou Antigravity. L’outil change, pas les étapes.

Étape 1. Crée l’étiquette avant de commencer

La première chose à faire est d’avoir déjà créé dans WordPress l’étiquette que tu veux appliquer.

Il vaut mieux le faire manuellement, car je ne veux pas que Codex décide de l’organisation de la taxonomie du site. Nous voulons simplement qu’il localise quelque chose qui existe déjà et l’assigne à certains articles.

Dans WordPress, tu le sais, tu peux le faire depuis :

Articles > Étiquettes

Si ton site n’a qu’une seule langue, tu as pratiquement terminé cette étape.

Si tu utilises Polylang (version Pro ou avec ton propre développement par-dessus, comme dans mon cas), crée aussi les traductions de l’étiquette et vérifie qu’elles sont correctement liées.

Par exemple, dans mon cas j’avais :

• Ciencia Ficción.
• Science Fiction.
• Science-fiction.
• Science-Fiction.
• Fantascienza.
• …

Et ainsi de suite.

WordPress les stocke en interne comme des termes (étiquettes) différents, et chacun aura son propre ID. Ce sera important plus tard.

Petite précision : j’ai un plugin maison qui les crée automatiquement dans toutes les langues, mais tu devras probablement les créer manuellement, une par une pour chaque langue.

Prompt pour vérifier les étiquettes

Une fois qu’elles sont créées, tu peux demander à Codex de les localiser :

Je veux ajouter une étiquette existante à plusieurs articles WordPress.

L’étiquette principale est :

[NOM DE L’ÉTIQUETTE]

Pour l’instant, ne modifie aucune donnée.

Localise l’étiquette dans WordPress et, si le site utilise Polylang, toutes ses traductions.

Renvoie-moi pour chaque langue :

– langue ;

– nom de l’étiquette ;

– slug ;

– term ID.

Ne crée pas de nouvelles étiquettes.

S’il manque une traduction, s’il y a des doublons ou la moindre ambiguïté, arrête-toi et préviens-moi.

Le term ID est simplement le numéro avec lequel WordPress identifie cette étiquette en interne. L’important est que Codex sache quel ID correspond à chaque langue.

Étape 2. Prépare une liste fermée d’articles

Nous devons maintenant décider quels articles nous voulons modifier.

Ici, je recommande de ne pas laisser trop de liberté à l’agent.

On pourrait lui demander :

Trouve tous les articles liés à la science-fiction et ajoute-leur l’étiquette.

Mais nous mélangerions alors deux tâches très différentes :

1. Décider éditorialement quels contenus doivent recevoir l’étiquette.
2. Effectuer 20, 100 ou 500 fois la même modification dans WordPress.

Je préfère séparer les deux pour garder le contrôle à chaque étape.

Tu peux établir la liste manuellement si le volume d’articles n’est pas très élevé.

Tu peux aussi utiliser ChatGPT ou Codex pour t’aider à repérer des candidats.

Dans mon cas, comme le volume était important, je lui ai fourni les trois sitemaps d’articles que j’ai et j’ai demandé à ChatGPT de me proposer des candidats en fonction de l’URL.

Quelle que soit ta méthode, tu devrais terminer avec une liste précise d’articles avant de modifier quoi que ce soit.

Par exemple :

• Blade Runner : critique et analyse.
• Les meilleurs comics de science-fiction.
• Akira : manga et film.
• El Eternauta : critique de la série.
• …

Comme je te l’ai dit, j’ai terminé avec 12 articles par langue, après avoir écarté quelques candidats que ChatGPT jugeait pertinents mais pas moi.

Prompt pour préparer le périmètre de travail

Une fois la liste prête, envoie ceci à Codex :

Je vais te fournir une liste fermée d’articles WordPress.

Travaille exclusivement sur ces articles.

N’ajoute aucun autre contenu, même si tu considères qu’il pourrait lui aussi correspondre à l’étiquette.

Liste :

[COLLE ICI LES TITRES OU URL]

Pour l’instant, ne fais aucune modification.

Localise chaque article et renvoie :

– titre ;

– URL ;

– post ID ;

– statut ;

– langue.

Si l’un d’eux ne peut pas être identifié sans ambiguïté, arrête-toi et signale-le.

Avec cela, nous avons défini les deux extrémités de l’opération :

1. Quels articles nous voulons étiqueter
2. Quelle étiquette nous voulons ajouter.

Étape 3. Configure l’accès de Codex à WordPress

Pour lire certaines propriétés de WordPress et, surtout, pour modifier des articles, Codex doit s’authentifier.

Il existe différentes façons de le faire, plus ou moins sûres. Une méthode assez pratique consiste à utiliser un mot de passe d’application WordPress.

Ce n’est pas ton mot de passe habituel pour accéder au tableau de bord. C’est un mot de passe supplémentaire créé spécialement pour qu’une application puisse se connecter à WordPress via l’ API REST. 

Tout comme tu peux le créer, tu peux le révoquer à tout moment sans devoir changer ton mot de passe habituel.

Il se crée depuis :

Utilisateurs > Profil > Mots de passe d’application

Donne-lui un nom qui te permettra de l’identifier ensuite, par exemple « Codex ».

WordPress générera un mot de passe.

Comment transmettre le mot de passe à Codex

Ne mets pas le mot de passe directement dans le prompt

Ça pourrait fonctionner, mais envoyer tes mots de passe dans le cloud n’est pas une bonne habitude.

L’idéal est de le stocker localement comme variable d’environnement ou dans un fichier .env qui ne soit pas envoyé dans le dépôt, si tu travailles avec Git.

Par exemple, tu peux enregistrer un fichier .env contenant uniquement ces trois lignes :

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Enregistre-le dans C:UsersTU_USUARIO_WINDOWS.codex.env

Et ajoute .env à .gitignore pour qu’il ne soit pas envoyé.

L’idée est que Codex puisse utiliser les identifiants sans avoir à les afficher ni à les recopier en permanence.

Une fois le fichier correspondant créé, tu dois fermer Codex puis le rouvrir pour qu’il le lise.

Deux choses importantes: 

1. Le nom d’utilisateur WordPress ne correspond pas forcément au nom public affiché comme auteur. Indique le véritable nom d’utilisateur dans le fichier.
2. La clé générée par WordPress contient des espaces. Supprime-les lorsque tu l’enregistres dans le .env. Sinon, cela ne fonctionnera pas.

Prompt pour cette partie

Après l’étape précédente, envoie ce prompt à Codex :

Utilise les identifiants WordPress disponibles dans les variables d’environnement locales.

N’affiche, n’imprime et ne copie aucun mot de passe, token ou autre secret dans la sortie.

Ne modifie encore aucun contenu.

Vérifie uniquement que les variables nécessaires sont disponibles.

De cette façon, tu sauras s’il les a bien récupérées, une étape indispensable avant de continuer.

Étape 4. Vérifie que Codex peut se connecter

L’étape suivante consiste à vérifier que la connexion fonctionne.

L’API REST est en gros l’interface par laquelle Codex peut demander à WordPress des choses comme Quelles étiquettes cet article possède-t-il ? ou Ajoute cette étiquette et enregistre l’article.

À ce stade, nous voulons uniquement faire la première chose. Demande-lui donc d’effectuer une requête en lecture seule :

Vérifie l’authentification auprès de l’API REST de WordPress.

Effectue uniquement des requêtes GET.

Confirme :

– que la connexion fonctionne ;

– quel utilisateur WordPress est authentifié ;

– que cet utilisateur a les droits pour modifier les articles sur lesquels nous allons travailler.

S’il y a la moindre erreur d’authentification ou de permissions, arrête-toi.

N’effectue aucune requête d’écriture.

Si tout va bien, nous avons accès. Si tu reçois une erreur 401, il faut généralement vérifier les identifiants.

Étape 5. Localise les traductions de chaque article

Cette étape n’est nécessaire que si ton site est multilingue.

Si tu utilises Polylang, nous ne voulons pas que Codex cherche les traductions en comparant les titres, car un titre peut énormément changer d’une langue à l’autre.

Nous voulons qu’il utilise les relations de traduction déjà présentes dans WordPress/Polylang.

Nous partons de chaque article original pour localiser ses versions linguistiques.

Le prompt

En partant exclusivement des articles de la liste approuvée, localise leurs traductions à l’aide des relations Polylang.

Ne cherche pas les traductions en fonction de la ressemblance des titres.

Pour chaque article, renvoie :

– article original ;

– langue ;

– titre de la traduction ;

– post ID ;

– URL.

Le site utilise les langues suivantes :

[LISTE DES LANGUES]

Chaque article devrait avoir :

[NOMBRE DE VERSIONS]

versions au total.

S’il manque une traduction ou si tu trouves une relation incohérente, arrête-toi et ne modifie rien.

Nous avons ici une vérification très simple qui vaut la peine d’être faite.

Si tu as 25 articles × 5 langues = 125 posts Codex devrait en trouver exactement 125.

S’il en trouve 124, il ne doit pas continuer.

Étape 6. Effectue un dry run complet

Nous avons maintenant suffisamment d’informations pour préparer l’opération réelle, mais nous n’allons toujours pas l’exécuter.

Nous allons d’abord faire un dry run, qui n’est rien d’autre qu’une simulation de ce qui se passerait si nous autorisions les modifications.

Nous voulons que Codex construise un tableau reliant article > langue > étiquette correspondante > état actuel.

Prompt

Effectue maintenant un dry run complet de l’opération.

N’effectue aucune requête POST, PUT, PATCH ou DELETE.

Pour chaque article inclus dans la liste validée :

1. Consulte ses étiquettes actuelles.

2. Identifie la langue de l’article.

3. Localise la traduction de la nouvelle étiquette qui correspond exactement à cette même langue.

4. Obtiens le term ID de cette étiquette.

5. Vérifie si ce term ID est déjà assigné à l’article.

6. Calcule à quoi ressemblerait le tableau final de tags après l’ajout, en conservant tous les term IDs existants.

La relation doit toujours être :

article en langue X → étiquette en langue X → term ID de cette étiquette.

N’assigne jamais le term ID de l’étiquette espagnole à un article dans une autre langue et n’utilise jamais une étiquette dont la langue ne correspond pas exactement à celle de l’article.

Renvoie un tableau avec :

– post ID ;

– langue de l’article ;

– titre ;

– tags actuels ;

– nom de l’étiquette correspondant à cette langue ;

– langue de l’étiquette ;

– term ID à ajouter ;

– s’il est déjà présent ;

– tags finaux prévus.

Vérifie explicitement que la langue de l’article et celle de l’étiquette correspondent dans tous les cas.

Si tu trouves un article pour lequel tu ne peux pas identifier sans ambiguïté l’étiquette dans la même langue, s’il manque une traduction de l’étiquette ou si les langues de l’article et de l’étiquette ne correspondent pas, arrête-toi et ne modifie rien.

À la fin, indique :

– nombre total d’articles ;

– articles qui nécessitent une modification ;

– articles qui contiennent déjà l’étiquette ;

– erreurs ou incohérences.

N’écris encore rien.

Cette étape présente deux avantages.

Le premier est évident : nous pouvons voir exactement ce que Codex compte faire.

Le second est que nous découvrirons les articles qui ont déjà l’étiquette.

Inutile de modifier à nouveau ces articles.

Dans mon cas, il y avait 120 articles, mais 2 étaient déjà correctement étiquetés (je l’avais fait manuellement).

Étape 7. Vérifie qu’aucune étiquette ne sera supprimée

C’est le point auquel je prêterais le plus d’attention.

Imagine qu’un article possède déjà ces étiquettes :

• Bitcoin.
• Investissement.
• Tutoriel.

Et nous voulons ajouter « Fiscalité ».

Le résultat recherché est évidemment que l’article contienne les quatre, pas seulement Fiscalité.

Cela paraît évident, mais lorsque tu travailles via l’API REST, il faut garder à l’esprit que le champ tags représente l’ensemble des étiquettes que l’article doit posséder.

C’est pourquoi Codex doit d’abord lire les IDs existants, ajouter le nouveau, puis envoyer l’ensemble complet.

Nous ne voulons pas remplacer, nous voulons ajouter.

Tu peux le renforcer avec un prompt spécifique :

Avant d’exécuter les modifications, vérifie cette règle :

NE remplace JAMAIS les étiquettes actuelles de l’article par la seule nouvelle étiquette.

Pour chaque article :

1. Lis le tableau actuel des term IDs.

2. Conserve tous les IDs existants.

3. Vérifie si le nouveau term ID existe déjà.

4. S’il n’existe pas, ajoute-le au tableau.

5. Ne supprime ni ne modifie aucun autre term ID.

Montre-moi tout cas dans lequel tu ne peux pas garantir cette opération.

N’écris pas encore.

Si tu automatises une opération de ce type, je ne sauterais pas cette vérification.

Étape 8. Revalide tout juste avant de modifier WordPress

Le dry run est déjà approuvé. Nous pourrions exécuter directement, mais cela coûte très peu de relire WordPress juste avant d’écrire.

La raison est simple : l’état d’un article peut avoir changé entre deux requêtes. Peut-être l’as-tu modifié toi-même à des jours différents, ou quelqu’un d’autre l’a fait. Nous voulons nous assurer que Codex travaille sur la version actuelle.

Prompt

Effectue une revalidation immédiatement avant d’exécuter les modifications.

Consulte de nouveau WordPress et confirme :

– que tous les articles prévus existent toujours ;

– que les relations de traduction n’ont pas changé ;

– que les term IDs de l’étiquette sont toujours corrects ;

– que les étiquettes actuelles correspondent à l’état que tu vas modifier.

S’il existe la moindre différence par rapport au dry run, arrête-toi.

Si tout correspond, indique-moi :

– nombre total d’articles ;

– modifications nécessaires ;

– articles qui sont déjà corrects.

N’exécute encore aucune modification tant que je ne t’ai pas donné mon autorisation.

Nous réduisons ainsi considérablement le risque.

Étape 9. Exécute la modification

Si tout ce qui précède est OK, nous pouvons maintenant autoriser l’écriture.

À ce stade, il vaut mieux être très précis sur ce qui peut et ne peut pas être modifié.

Prompt

J’autorise l’exécution des modifications.

Modifie exclusivement les articles inclus dans la liste validée.

Pour chaque article :

1. Lis ses tags actuels.

2. Identifie la langue de l’article.

3. Utilise exclusivement la traduction de la nouvelle étiquette dont la langue correspond exactement à celle de cet article.

4. Obtiens le term ID de cette étiquette.

5. Vérifie si ce term ID est déjà présent.

6. S’il n’est pas présent, ajoute-le au tableau actuel de tags.

7. Conserve tous les autres term IDs existants.

8. Enregistre le tableau complet obtenu.

La relation doit toujours être :

article en langue X → étiquette en langue X → term ID de cette étiquette.

N’assigne jamais le term ID de l’étiquette espagnole à un article dans une autre langue et n’utilise jamais une étiquette dont la langue ne correspond pas exactement à celle de l’article.

Si, pour un article, tu ne peux pas identifier sans ambiguïté l’étiquette dans la même langue, s’il manque une traduction de l’étiquette ou si les langues de l’article et de l’étiquette ne correspondent pas, ne modifie pas cet article et consigne l’erreur.

NE modifie PAS :

– titre ;

– contenu ;

– extrait ;

– slug ;

– catégories ;

– auteur ;

– date ;

– statut ;

– image mise en avant ;

– champs ACF ;

– SEO ;

– aucune autre donnée de l’article.

Ne modifie aucun article en dehors de la liste approuvée.

Consigne pour chaque opération :

– post ID ;

– langue de l’article ;

– nom de l’étiquette assignée ;

– langue de l’étiquette ;

– term ID ajouté ;

– tags avant ;

– tags après ;

– code de réponse de WordPress ;

– résultat.

Si une opération échoue, consigne l’erreur et n’essaie pas de la corriger en modifiant d’autres champs.

Codex effectuera maintenant les requêtes nécessaires auprès de WordPress.

Mais il nous reste encore une vérification.

Étape 10. Relis tous les articles

Une réponse correcte de l’API signifie que WordPress a accepté la requête.

Mais si nous travaillons avec des dizaines ou des centaines d’articles, cela vaut la peine de vérifier l’état final, au lieu de simplement supposer que tout s’est bien passé.

Nous faisons donc une nouvelle série de requêtes de lecture.

Prompt

Une fois les modifications terminées, effectue une vérification indépendante au moyen de nouvelles requêtes GET.

Pour chaque article de la liste, vérifie :

1. Qu’il contient le term ID de la nouvelle étiquette correspondant à sa langue.

2. Qu’il conserve tous les term IDs qu’il avait auparavant.

3. Qu’aucune étiquette inattendue n’a été ajoutée.

4. Qu’aucun article en dehors de la liste n’a été modifié.

Renvoie un résumé final avec :

– articles vérifiés ;

– modifications effectuées ;

– articles qui étaient déjà correctement étiquetés ;

– erreurs REST ;

– anciennes étiquettes perdues ;

– articles modifiés de manière inattendue ;

– écarts finaux.

Considère la tâche comme terminée uniquement s’il y a 0 écart.

Le processus est ainsi bouclé.

Nous n’avons pas seulement effectué les modifications, nous avons aussi vérifié ce qui a réellement été enregistré correctement dans WordPress.

Conclusions

La première, c’est que pour quelques articles, il reste probablement plus rapide de le faire à la main. Mais l’échelle change vite, surtout avec le multilingue :

• 10 articles × 10 langues = 100 posts
• 30 articles × 10 langues = 300 posts
• 50 articles × 10 langues = 500 posts

À ce stade, il ne s’agit plus seulement d’économiser des clics, mais surtout de réduire les erreurs.

L’idée que je veux que tu retiennes, car je la trouve vraiment utile dans ce système, est que Codex ne décide pas et ne modifie pas librement ton WordPress:

• Il construit d’abord le système.
• Puis il simule.
• Ensuite il revalide.
• Ce n’est qu’alors qu’il écrit.
• Et une fois terminé, il vérifie de nouveau l’ensemble.

Pour la maintenance éditoriale à grande échelle, cela me paraît une façon bien plus sensée d’utiliser des agents comme Codex.

En fait, j’ai déjà très clairement en tête une autre modification qui touche plus de 500 articles et que je pensais faire à la main en SQL. 

Après avoir testé cette méthode, il est clair pour moi qu’elle est bien meilleure et que les probabilités d’erreur diminuent considérablement.

Ça a été un aller simple.