Transparence : je développe l'app Mac ShipPress, que je présente rapidement à la fin. Les conseils qui précèdent marchent très bien sans mon outil.
Claude Code ou Codex savent maintenant faire beaucoup de choses sur un thème ou des pages WordPress. Mais un agent déborde parfois de sa mission : il modifie des fichiers qu'il ne devait pas toucher, ou écrit directement dans la base de données. Voici cinq habitudes que j'aurais aimé prendre dès le début, après quelques mois à faire travailler l'IA sur WordPress.
1. Travailler en local ou en préproduction, jamais en production
Ça paraît évident, et c'est pourtant ce qui protège le plus. Ne laissez pas l'agent travailler en SSH sur le site en ligne. Modifiez en local ou sur un staging, vérifiez, puis seulement ensuite publiez.
wp-env, Local ou Docker, peu importe. Ce qui compte, c'est d'avoir un endroit où casser quelque chose ne gêne personne.
2. Limiter le répertoire de travail
Si vous donnez à l'agent tout le dépôt ou la racine WordPress, il lira aussi wp-config.php et les fichiers du cœur. S'il ne doit toucher qu'au thème, lancez-le dans le dossier du thème :
cd wp-content/themes/mon-theme
claude # ou codex, etc.
Avec Claude Code, un fichier CLAUDE.md dans le projet permet en plus d'écrire noir sur blanc ce qui est autorisé :
## Règles
- Ne modifier que les fichiers sous wp-content/themes/mon-theme
- Ne pas lire ni modifier wp-config.php ni les fichiers du cœur
- Proposer de nouvelles extensions, sans les installer soi-même
3. Sauvegarder la base de données, pas seulement les fichiers
Git permet de revenir en arrière sur les fichiers. Mais les articles, les pages, les menus et les modifications des modèles d'un thème de blocs vivent dans la base. Git seul ne vous rendra pas une page créée par l'IA.
Avant chaque session, un export avec WP-CLI :
# avant
wp db export backups/avant-ia-$(date +%Y%m%d-%H%M).sql
# retour arrière si besoin
wp db import backups/avant-ia-20261028-1300.sql
Et côté fichiers, un commit après chaque étape :
git add -A && git commit -m "avant : changement de couleur du header"
4. Donner des tâches courtes
« Construis-moi tout le site » est bien plus difficile à vérifier et à annuler que « Construis seulement la section hero de l'accueil ». En avançant par petits tours (demande, vérification, sauvegarde), on voit tout de suite quelle consigne a cassé quelque chose.
5. Relire le diff avant de déployer
Avant toute mise en ligne, je vérifie au minimum ceci :
git diff --stat # quels fichiers ont changé
wp plugin list --status=active # une extension inconnue est-elle apparue ?
wp option get siteurl # l'URL a-t-elle été réécrite ?
Si siteurl ou home arrivent en production avec l'URL locale, le site devient inaccessible. Ça mérite un second coup d'œil.
En résumé
- Travailler en local ou en préproduction
- Limiter le périmètre de l'agent
- Fichiers avec git, base de données avec
wp db export - Petites tâches, vérification à chaque étape
- Contrôler le diff et les réglages avant le déploiement
Au passage : une app qui fait ça automatiquement
Les étapes 1 à 3 me demandaient trop de travail manuel à chaque fois, alors j'ai créé ShipPress, une app Mac gratuite. Elle installe un WordPress local, laisse votre CLI d'IA existante (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) construire le site, et crée un point de restauration à chaque modification de l'IA. Pour publier, il y a des intégrations d'hébergeurs comme InstaWP, le SSH ou un export statique.
Téléchargement : https://shippress.codotx.com/?ref=devto-fr
Si vous avez vos propres astuces pour faire travailler un agent IA sur WordPress sans risque, je serais ravi de les lire en commentaire.
Oberon Lai
Top comments (0)