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.
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.
