# Claude Code et WP-CLI sur un projet WordPress : notre retour

> Un mois avec Claude Code branché sur un vrai projet WordPress en production : tâches confiées, garde-fous posés, ce qui a marché et ce qui a échoué.

- Auteur : Clément Hadrot
- Publié le : 2025-02-27
- Mis à jour le : 2025-02-27
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/claude-code-wp-cli-wordpress/

## L’essentiel

- Un agent en terminal accède directement à WP-CLI et au système de fichiers
- Les garde-fous comptent plus que la puissance du modèle
- Les tâches répétitives gagnent, les décisions de design perdent

Depuis un mois, nous laissons Claude Code intervenir sur un projet WordPress client, un site vitrine avec une boutique WooCommerce annexe, hébergé sur notre infrastructure habituelle. L'idée n'était pas de tester un chatbot mais un agent capable d'ouvrir un terminal, de lire des fichiers, d'exécuter des commandes WP-CLI et de proposer des correctifs directement dans le dépôt Git du projet. Ce n'est pas un article sur les serveurs MCP : ici, l'agent travaille en ligne de commande, sans couche d'intégration supplémentaire côté site.

Nous avons tenu un journal de chaque intervention, avec la tâche confiée, le temps passé à la superviser et le résultat final. Dix-huit tâches plus tard, voici ce que nous en retenons, dans le détail, sans enjoliver les échecs.

## Ce que nous avons confié à l'agent

Les tâches allaient de la plus mécanique à la plus ouverte : mise à jour de plugins avec vérification des changelogs, correction d'un avertissement PHP 8.2 sur une fonction dépréciée, ajout d'un champ ACF avec sa migration, nettoyage de transients orphelins, ou encore rédaction d'un rapport de performance après un audit avec `wp profile stage`. Sur les tâches mécaniques, l'agent a été systématiquement plus rapide qu'un développeur junior, en particulier sur l'exploration du code existant avant modification.

## Les garde-fous que nous avons posés

Aucune commande destructive n'était autorisée sans validation explicite : suppression de contenu, modification de la base en production, ou `wp db query` sur des données réelles restaient bloquées derrière une confirmation manuelle. Nous avons aussi interdit tout push direct sur la branche principale, l'agent travaillant systématiquement sur une branche dédiée avec revue de code avant fusion, exactement comme pour un contributeur humain.

> L'essentiel à retenir : Un agent en terminal accède directement à WP-CLI et au système de fichiers ; Les garde-fous comptent plus que la puissance du modèle ; Les tâches répétitives gagnent, les décisions de design perdent

## Les réussites concrètes

Le cas le plus net : une migration de champs personnalisés vers ACF sur environ 3 000 articles. L'agent a écrit un script WP-CLI avec `wp eval-file`, l'a testé sur un environnement de recette cloné avec `wp db export` puis import local, corrigé lui-même une erreur de type sur un champ numérique, et livré un script prêt à exécuter en production avec sauvegarde préalable documentée. Un développeur aurait probablement mis une demi-journée ; l'agent a livré une première version exploitable en moins de vingt minutes, supervision comprise.

## Les échecs et leurs raisons

À l'inverse, sur une tâche de refonte d'un formulaire de contact avec logique conditionnelle complexe, l'agent a proposé une solution fonctionnelle mais qui ignorait une contrainte métier non documentée dans le code : un champ devait rester obligatoire uniquement pour certains types de clients, une règle connue seulement de l'équipe commerciale. Ce n'est pas un problème de compétence technique mais de contexte manquant, ce que ni WP-CLI ni le code source ne pouvaient révéler seuls.

### Le piège de la confiance excessive

Deuxième échec instructif : sur une tâche de nettoyage de la base, l'agent a proposé de supprimer des `post_meta` qu'il jugeait orphelins après une analyse du code actif, sans détecter qu'ils étaient encore lus par un script cron externe non versionné dans le dépôt. Nous avons évité l'incident uniquement grâce au garde-fou de validation manuelle sur les suppressions.

- Toujours travailler sur une branche dédiée avec revue avant fusion
- Bloquer les commandes destructives derrière une confirmation explicite
- Tester sur un clone de la base avant toute exécution en production
- Documenter les règles métier absentes du code dans un fichier de contexte dédié

> L'agent ne remplace pas la connaissance du métier, il expose ce qui manque dans la documentation du projet.

## Notre verdict après un mois

Sur les dix-huit tâches confiées, treize ont été livrées sans retouche significative, trois ont nécessité une correction mineure et deux ont dû être reprises entièrement par un développeur. Le gain de temps est réel sur les tâches mécaniques et répétitives, mais nous continuons à garder un humain dans la boucle pour toute décision touchant à la logique métier ou aux données de production. C'est ce dosage, plus que la puissance brute du modèle, qui a fait la différence sur ce projet.