Claude Code est conçu pour le code, pas pour WordPress, mais l'agence WordPress qui utilise bien Claude Code aujourd'hui livre le travail à une vélocité environ 3x supérieure à celle qui ne l'utilise pas. Je dirige Seahawk Media, une agence qui a livré plus de 12 000 sites WordPress depuis 2018. La plupart de notre équipe utilise Claude Code quotidiennement pour le travail qui représentait autrefois les 70 pour cent ennuyeux du développement WordPress : l'échafaudage de thème, le débogage de plugin, la génération de schéma, la migration de contenu, les points de terminaison API REST personnalisés, et la longue traîne de tickets « répare ce problème PHP ». Ceci est le flux de travail réel.WordPress, but the WordPress agency that runs Claude Code well today ships work at roughly 3x the velocity of one that does not. I run Seahawk Media, an agency that has shipped 12,000+ WordPress sites since 2018. Most of our team uses Claude Code daily for the work that used to be the boring 70 percent of WordPress development: theme scaffolding, plugin debugging, schema generation, content migration, REST API custom endpoints, and the long tail of "fix this PHP issue" tickets. This is the actual workflow.
Si vous vous demandez si Claude Code est vraiment viable pour le travail WordPress spécifiquement, la réponse opérationnelle est oui, avec une configuration différente de celle que vous utiliseriez pour Vue ou Next.js, et uniquement si vous traitez les idiomes WordPress comme du contexte de première classe.Next.js, and only if you treat the WordPress idioms as first-class context.
Pourquoi la plupart des équipes WordPress utilisent mal Claude Code
La plupart des équipes ouvrent Claude Code à la racine WordPress, demandent à Claude d'écrire un bloc personnalisé, et obtiennent quelque chose qui compile mais ne correspond pas aux standards de code de l'équipe, n'enregistre pas le bloc correctement, et ne gère pas le rendu côté serveur PHP. La sortie paraît plausible à quelqu'un qui ne connaît pas WordPress ; elle échoue de façons subtiles pour quelqu'un qui connaît la plateforme.
La solution est le contexte. Claude ne connaît pas vos conventions WordPress jusqu'à ce que vous les lui disiez. Un court CLAUDE.md à la racine du projet avec vos standards de bloc, votre style de code PHP, vos conventions de test, et votre flux de déploiement transforme Claude d'un outil générique conscient de PHP en un collaborateur WordPress spécifique au projet. Les 30 minutes d'authoring de CLAUDE.md constituent l'investissement en temps au plus haut levier que j'aie fait du côté WordPress de notre travail.
Le CLAUDE.md que j'exécute sur chaque projet WordPress
Une version du modèle CLAUDE.md que nous utilisons dans les engagements clients de Seahawk :
Contexte du projet : nom du client, domaine principal, hébergement (Kinsta, WP Engine, Cloudways), version WordPress, version PHP, thème, plugins clés.
Normes de codage : WordPress Coding Standards (WPCS) pour PHP, conditions Yoda ou non, conventions de préfixe pour les fonctions et les variables globales, convention de nommage pour les types de posts personnalisés et les taxonomies.
Normes de blocs : blocs rendus côté serveur pour les blocs de contenu, ACF Pro pour les champs éditoriaux, Bricks Builder si utilisé, Gutenberg sinon. Modèles d'enregistrement de blocs sur lesquels l'équipe s'est mise d'accord.
Conventions de test : PHPUnit pour PHP, Jest pour JS dans les blocs, Cypress pour E2E le cas échéant. Où les tests se trouvent dans l'arborescence du projet.
Flux de déploiement : comment pousser vers la staging, comment pousser vers la production, ce qui est mis à jour où.
Modèles interdits : choses à ne jamais faire (eval, query_posts, requêtes directes à la base de données sans déclarations préparées, etc.).
C'est deux pages d'anglais pur. Claude le lit une fois, et chaque session suivante de génération de code du projet est calibrée sur vos normes plutôt que sur les défauts WordPress génériques.
Des workflows WordPress spécifiques qui se compressent massivement
Génération manuelle de blocs personnalisés
De l'idée au bloc rendu côté serveur : 90 minutes manuellement, 10 minutes avec Claude Code si le CLAUDE.md est bon. Claude génère l'enregistrement PHP, le JSX pour l'éditeur, le modèle rendu côté serveur, le block.json et les contrôles côté éditeur. Je examine le diff et corrige un ou deux problèmes de style. Le travail fastidieux de génération est disparu.
Débogage des conflits de plugin
Claude lit le journal d'erreurs, cherche le hook problématique dans le répertoire des plugins, identifie le conflit et propose une correction. Le travail de détective qui prend 30 à 60 minutes manuellement prend 5 minutes dans Claude Code. On a détecté un conflit Yoast / RankMath lors d'une migration récente dans le temps qu'il faut pour préparer un café.
Balisage de schéma à grande échelle
Claude génère le schéma par type de page (Article, BlogPosting, Product, FAQPage, Organization, BreadcrumbList) en suivant les conventions de nommage du projet. Trois à cinq types de pages, couverture complète du schéma, en environ 30 minutes. Le schéma aurait été un travail d'une demi-journée pour un développeur junior.
Scripts de migration de contenu
WP-CLI plus Claude est véritablement une catégorie d'outil différente de WP-CLI seul. On a migré 8 000 articles d'un CMS personnalisé vers WordPress lors d'un engagement récent. Claude a écrit les commandes WP-CLI, le script de nettoyage post-import, la génération de la carte de redirection et la déduplication d'URL. Trois jours de travail en une demi-journée.
Points de terminaison personnalisés de l'API REST
De la spécification du produit au point de terminaison fonctionnel avec rappels de permission, validation du schéma et couverture des tests : moins d'une heure. Le boilerplate qui fait fonctionner l'API REST de WordPress disparaît dans la sortie de Claude.
Ce que Claude Code ne gère pas bien dans WordPress
Trois domaines où Claude a des limites suffisantes pour que je considère l'humain comme l'ingénieur senior :
Les décisions d'architecture de thème. Quand il s'agit de choisir entre des thèmes de blocs, des thèmes classiques avec FSE, Bricks ou une approche entièrement headless, les compromis sont spécifiques au projet et Claude n'a pas le contexte éditorial de votre client. C'est un travail humain.
La sélection de plugins. Claude peut comparer les fonctionnalités des plugins mais ne sait pas quels plugins votre équipe a eu des mauvaises expériences avec, lesquels l'hébergeur du client bloque, ou lesquels cassent sur PHP 8.3. Choisissez les plugins vous-même ; laissez Claude les intégrer.
L'UX des blocs Gutenberg personnalisés. Claude génère des blocs qui fonctionnent ; il ne génère pas des expériences d'éditeur qui semblent polies. Les micro-interactions, le placement de la barre d'outils, la disposition des InspectorControls, le texte d'état vide, ce sont des décisions de design, pas des résultats de génération de code.
La chaîne d'outils que j'utilise réellement
Claude Code comme surface principale, avec les ajouts MCP spécifiques à WordPress :
Filesystem MCP, intégré. Lit la base de code WordPress, les fichiers de thème, le répertoire des plugins.
Postgres ou MySQL MCP, pour les audits de contenu et les travaux de migration. Exécutez SQL directement contre les tables wp_posts et wp_postmeta.
Puppeteer MCP, pour crawler le site rendu et vérifier que les modifications ont bien été déployées.
WP-CLI via le shell, Claude invoque directement les commandes wp quand c'est nécessaire.
Plus un CLAUDE.md existant par projet. C'est toute la stack.
Conclusion
Claude Code pour WordPress est réel, le workflow diffère de l'utilisation générique de Claude Code, et le CLAUDE.md par projet est l'investissement le plus rentable que peut faire une agence WordPress en 30 minutes cette année. On déploie plus vite, on corrige plus vite, et on détecte les conflits de plugins plus vite qu'avant.
Chez Seahawk Media, on utilise maintenant le développement WordPress assisté par IA sur chaque engagement client. La première conversation est gratuite ; la recommandation est honnête quant à savoir si l'IA assistée convient à ton projet WordPress spécifique.
Questions fréquemment posées
Peut-on utiliser Claude Code pour le développement WordPress ?
Oui. Claude Code est conçu pour les travaux logiciels généraux, pas spécifiquement pour WordPress, mais il gère bien le code des thèmes et extensions, les outils de build, les migrations et l'automatisation. Les agences qui en tirent profit l'associent à un CLAUDE.md clair et une configuration MCP pour qu'il comprenne le contexte WordPress.
Claude Code accélère-t-il le développement WordPress ?
Pour les équipes qui le configurent bien, oui, de manière significative. La vitesse vient de l'automatisation du code répétitif, du scaffolding et des audits, pas de la magie. Un CLAUDE.md discipliné, un workflow éprouvé et une relecture humaine sur chaque modification, voilà ce qui transforme cela en vraie vélocité plutôt qu'en erreurs rapides.
Que faut-il pour utiliser Claude Code pour WordPress ?
Un CLAUDE.md clair décrivant vos standards et votre stack, une configuration MCP pour les outils et données auxquels il doit accéder, et l'habitude de relire chaque modification. Sans cela, le résultat est générique. Avec cela, Claude Code devient un pair rapide et conscient du contexte pour le travail sur thèmes, extensions et migrations.
Claude Code est-il meilleur que de copier depuis ChatGPT pour WordPress ?
Pour un vrai travail de projet, oui, parce que Claude Code s'exécute dans votre codebase avec vos fichiers, standards et outils, au lieu de produire des snippets que vous collez à l'aveugle. Il lit le code réel, apporte des modifications en contexte et exécute des vérifications. C'est le contexte qui fait la différence, pas seulement le modèle sous-jacent.