ChatGPT, WordPress et WP-CLI : je ne veux plus servir d’intermédiaire

Lors de mes précédentes expériences avec ChatGPT et WordPress, j’avais réussi à franchir une étape importante : utiliser WP-CLI pour permettre à l’IA d’interroger réellement mon installation WordPress.

Nous avions notamment travaillé sur le footer multilingue de Subsahara.org. Au lieu de me contenter de captures d’écran et d’explications, ChatGPT pouvait me demander d’interroger WordPress : version installée, thèmes, plugins, contenus enregistrés en base de données, template parts…

Cela fonctionnait.

Mais il restait un problème que je n’avais peut-être pas suffisamment mesuré :

c’était toujours moi qui faisais le lien entre ChatGPT et WordPress.

Une nouvelle séance qui commence mal

Pour cette nouvelle expérience, j’ai relancé mon installation locale de Subsahara.org avec Local.

L’idée était simple : laisser ChatGPT commencer par auditer WordPress avant de décider quoi modifier.

Première commande, premier problème.

WP-CLI n’arrivait plus à communiquer correctement avec l’environnement. Puis, après quelques vérifications, le diagnostic est devenu plus précis : WordPress fonctionnait, le site local fonctionnait et la base MySQL était parfaitement accessible avec AdminerNeo.

En revanche, le « Site Shell » de Local affichait :

Setting Local environment variables...
Accès refusé.
Accès refusé.
...

Puis :

'wp' n’est pas reconnu...
'composer' n’est pas reconnu...
'php' n’est pas reconnu...
'mysql' n’est pas reconnu...

Nous aurions pu continuer.

Chercher les journaux de Local, examiner Windows, comprendre pourquoi l’environnement du terminal n’était plus correctement initialisé…

Et c’est précisément à ce moment-là que je me suis posé une autre question :

Pourquoi suis-je en train de faire tout cela ?

WP-CLI reste pourtant très intéressant

Le problème n’est pas WP-CLI.

Au contraire, je comprends maintenant beaucoup mieux son intérêt dans un projet associant WordPress et intelligence artificielle.

WordPress ne se résume pas aux fichiers présents dans wp-content.

Une partie importante du site se trouve dans sa base de données : pages, options, contenus Gutenberg et, avec les thèmes blocs, des personnalisations de templates et de template parts.

Codex peut travailler directement sur les fichiers de mon installation locale.

WP-CLI peut, lui, interroger WordPress.

Une commande peut par exemple récupérer le contenu réellement enregistré d’un élément WordPress :

wp post get 29 --field=post_content

Une autre peut connaître l’adresse configurée du site :

wp option get home

Ou dresser la liste des plugins :

wp plugin list

Pour une IA chargée d’analyser une installation WordPress, cette interface est extrêmement intéressante.

Mais je ne veux plus être l’API

C’est finalement la principale leçon de cette soirée.

Notre fonctionnement ressemblait encore trop souvent à ceci :

ChatGPT → me donne une commande → je la copie dans le terminal → je récupère le résultat → je le colle dans ChatGPT → ChatGPT me donne la commande suivante…

Techniquement, cela fonctionne.

Mais ce n’est pas ma conception d’une IA qui travaille avec WordPress.

Je ne veux pas devenir l’interface de communication entre deux logiciels.

D’autant que j’utilise déjà Codex, qui peut travailler directement dans les fichiers de mes installations locales.

La question devient donc beaucoup plus intéressante.

Et si Codex utilisait lui-même WP-CLI ?

Je commence à entrevoir une autre organisation :

Moi → ChatGPT → Codex → WordPress local

Mon rôle serait de définir l’objectif.

Par exemple :

Améliore le footer de ce site, mais ne touche pas à la production.

ChatGPT pourrait réfléchir à la stratégie, aux contrôles nécessaires et aux risques.

Codex disposerait de l’environnement de développement et pourrait examiner les fichiers, effectuer les modifications et, lorsque c’est nécessaire, utiliser WP-CLI pour interroger WordPress.

Enfin, je retrouverais le rôle qui me paraît le plus logique :

regarder le résultat dans mon navigateur et décider si je le valide.

L’échec était finalement utile

Nous n’avons donc rien modifié dans WordPress ce soir.

Et c’est peut-être le résultat le plus intéressant de l’expérience.

Notre principe de départ reste valable :

WordPress de test → contrôles → validation humaine → production.

Mais une nouvelle exigence vient de s’y ajouter :

l’humain ne doit pas devenir le câble USB entre les différentes IA et WordPress.

WP-CLI reste un excellent outil.

Simplement, ce n’est probablement pas moi qui dois l’utiliser.

La prochaine expérience sera donc différente.

Il ne s’agira plus d’apprendre à utiliser davantage WP-CLI.

Il s’agira de voir si ChatGPT et Codex peuvent réellement travailler ensemble sur mon WordPress local, sans que j’aie à copier-coller leurs commandes toute la soirée.

Et là, nous commencerons peut-être vraiment à parler d’un atelier WordPress assisté par l’IA.

---

vidIQ