J’ai testé 7 façons de créer une page WordPress avec Claude Code (mai 2026)

Créer une page WordPress qui sorte du carcan "site IA-généré conventionnel" tout en restant éditable par un rédacteur non-technique, en 2026, c’est plus de chemins qu’on ne le croit.

J’ai testé 7 manières différentes de bâtir la même maquette. Une direction visuelle brutalist-éditoriale baptisée "Direction B Lab", avec une palette nerveuse (bone clair, ink noir profond, acid vert citron, violet électrique) et deux typographies travaillées (Space Grotesk pour les titres, JetBrains Mono pour les annotations).

Voici à quoi ressemble la solution retenue, M-07, en page live :

Même maquette, même contenu, 7 trajectoires techniques. Résultat : 8 pages live sur test.wpformation.com, gelées 12 mois minimum, à comparer dans votre navigateur.

L’article ne cherche pas à vous imposer une seule bonne réponse. Il présente la gamme complète et vous laisse arbitrer selon votre profil.

Site indépendant sans plugin tiers, refonte marketing pro avec design system rigoureux, landing one-shot livrée par un graphiste, formation pour débutants WordPress : chaque cas appelle une méthode différente.

Pour ma part, j’ai une préférence claire pour M-07 sur les projets ambitieux côté design. Mais je tiens à dire qu’elle dépend du contexte, pas qu’elle s’impose dans l’absolu. La force réelle, c’est de maîtriser la gamme entière. Une fois familiarisé avec les 7 méthodes et leurs compromis, livrer un site WordPress superbe devient bien plus facile, sans renier ce qui fait le sel et la force de WP.

Pour le contexte général Claude Code et WordPress, lisez en complément l’article pilier sur Claude Code et WordPress.

Avant d’attaquer les 7 sections détaillées, le diaporama ci-dessous vous donne un aperçu visuel des 7 rendus. Même contenu, même direction artistique, sept techniques différentes : le résultat est plus contrasté qu’on ne le croit.

D’où vient l’idée de ce test ?

Tout est parti d’un projet de stagiaire. En accompagnant Alexandra sur sa refonte WordPress, j’ai vu défiler les choix techniques classiques : thème, plugin constructeur de pages, blocs custom, CSS dans un fichier enfant.

Je me suis dit qu’il manquait un comparatif honnête entre toutes ces voies. Plutôt que de trancher au feeling, j’ai posé un protocole.

Le document tient en 35 Ko, contient le design system, la structure des 10 sections, les contenus prêts à coller, les 5 snippets CSS, le markup Gutenberg canonique, et la checklist QA de 15 points. Le même brief, donné à Claude Code, reproduit sept fois avec sept techniques différentes. Chaque méthode reçoit le même contenu, la même direction artistique. Seule la technique change.

Côté clavier, j’ai travaillé avec Claude Code (Opus 4.7) en mode Auto. L’IA a sorti 1 158 lignes de CSS en quelques heures, généré 11 blocs PHP avec leur render.php, écrit les scripts de déploiement REST avec retry sur 429, et les captures Playwright de validation.

Je fixais les objectifs, l’orientation, le verdict. Claude exécutait et proposait. Une vraie collaboration humain plus IA, où chaque rôle est clair.

Comment j’ai testé ?

L’enjeu d’un comparatif honnête : rejouer la même maquette avec chaque méthode. Sinon, le ressenti design biaise tout.

Direction B Lab a donc été implémentée 7 fois (plus une page HUB éditoriale d’entrée), avec la même structure de 10 sections : utility, localnav, banner, hero, stats, why, pillars, feature 2-col, methods-table, team, cta-final.

Mêmes contenus, mêmes typographies, mêmes couleurs. Seule la technique de construction change. Chaque résultat est noté sur 6 critères, avec une pondération qui reflète les priorités d’un site WordPress en production. Score brut sur 30, score pondéré sur 37,5.

Critère	Description	Pondération
C1 Éditabilité Gutenberg	Un rédacteur peut-il modifier titre, lead, CTA depuis l’admin sans casser la mise en page ?	1,0
C2 Qualité visuelle	Le rendu front est-il pixel-conforme à la maquette de référence ?	2,0
C3 Indépendance plugin	Combien de plugins payants ou tiers la méthode exige-t-elle ?	1,5
C4 Reproductibilité scriptée	La méthode peut-elle être déployée en 1-shot via REST, Playwright, CLI ?	1,0
C5 Performance	Taille du post_content et poids des assets injectés en page	0,5
C6 Maintenabilité long-terme	Versionnable Git ? MAJ centralisée cross-pages possible ?	1,5

Pourquoi Claude Code et pas Claude.ai chat ni Cowork ?

Tout le lab tourne avec Claude Code dans VSCode, pas avec Claude.ai en chat ni avec le mode Cowork. Le choix est volontaire : je veux que l’IA voie le repo en entier, lise le fichier exact avant de l’éditer, exécute les scripts Playwright et les push REST WordPress sans copier-coller manuel. Claude.ai en chat est fantastique pour brainstormer, lire un PDF, drafter une lettre. Mais à partir du moment où il y a du code, un workflow CLI, des captures à orchestrer, je perds 80 % de mon temps en copier-coller entre fenêtres et à itérer si je reste dans le chat.

Claude Code plus VSCode, c’est ma machine, mon repo, mon historique git, mes MCP, mes skills personnels, mes agents. L’IA tape directement dans les fichiers que je travaille déjà, lance mes scripts, lit mes logs. Pour un lab comme celui-ci où il faut pousser 7 pages WP, capturer 14 screenshots, comparer 6 critères pondérés et publier un article de 5 000 mots, ce n’est plus une comparaison : le chat est inenvisageable.

Avant de plonger dans les 7 méthodes, un mot sur ce qui arrive en juin : je vous montre tout le protocole en direct, le 23 juin 2026 à 21h (heure de Paris), sur YouTube Live. Une heure de démo front et admin, anti-patterns corrigés, utilisation de Claude.ai/design, Q&R libre dans le chat YouTube, replay illimité sur la chaîne. Inscription gratuite juste en dessous.

Les 7 méthodes en compétition

Du baseline le plus simple jusqu’à la voie pro 2026. URL live, pitch, score, pour qui et pour qui pas.

Vous pouvez survoler les méthodes qui ne vous concernent pas : le tableau récapitulatif en bas reprend tout.

M-01 Gutenberg natif (la baseline qui fait peur)

Que rend WordPress "tel quel", sans CSS personnalisé, sans plugin tiers, juste avec les blocs core et les styles par défaut du thème Astra ?

La page accueil-gutenberg-natif répond. Résultat honnête : un design "wireframe", parfaitement éditable mais visuellement faible pour 2026. C’est la baseline qu’il faut connaître avant de prétendre faire mieux. Et c’est exactement ce que livrent en silence beaucoup d’agences low-cost.

• 100 % blocs core/*, aucune meta CSS, aucun plugin
• Éditable par n’importe quel rédacteur
• Pour qui : pages brouillons, sites one-off non-techniques, formations débutants
• Pas adapté : refonte marketing pro avec exigence design

Score : 25 sur 30 brut, 29,5 sur 37,5 pondéré. Rang 4.

M-02 Méthode WPFormation – Gutenberg natif + CSS personnalisé page-level

La voie WPFormation que j’utilise depuis plusieurs mois sur des sites clients en production. Le pattern est simple : on garde des blocs Gutenberg natifs côté éditeur (le rédacteur reste autonome), et on injecte un CSS sur-mesure scopé à la page pour pousser le rendu visuel.

Le CSS est scopé body.page-id-XXX pour ne pas leaker ailleurs sur le site. Page live : methode-wpformation.

Comment le CSS rejoint la page : plusieurs canaux possibles selon votre stack. Le plus simple en 2026 = la meta _uag_custom_page_level_css exposée par le plugin Spectra gratuit (présent par défaut sur beaucoup de sites WP). On peut aussi passer par le customizer, un child theme, ou un plugin générique de CSS additionnel. Le pattern reste le même.

Design pixel-conforme à la maquette, markup parfaitement éditable. Le seul vrai coût : maintenir un CSS sur-mesure que personne d’autre dans l’équipe ne sait éditer.

• Markup blocs core/* natifs, design via CSS sur-mesure scopé page
• Injection CSS : meta Spectra gratuit, customizer, child theme – au choix selon votre stack
• Pour qui : sites marketing custom, 1 dev plus N rédacteurs, projets existants
• Pas adapté : équipes sans personne capable de maintenir le CSS sur-mesure

Score : 24 sur 30 brut, 30,5 sur 37,5 pondéré. Rang 3.

M-03 HTML monobloc (un seul wp:html géant)

Le designer livre, le contenu fige. Un seul bloc Custom HTML contient TOUT le markup et le <style> inline.

Page live : methode-html-monobloc. Design pixel-perfect, zéro plugin. MAIS le rédacteur qui ouvre l’éditeur ne voit que du code, ne peut rien modifier sans risque. C’est le modèle "page livrée par un graphiste, jamais retouchée en BO".

• 1 seul bloc core/html contenant tout : HTML et style inline
• Aucune dépendance plugin, rendu pixel-perfect
• Pour qui : landing one-shot livrée par graphiste, jamais éditée
• Pas adapté : tout site avec évolution éditoriale prévue

Score : 19 sur 30 brut, 25,5 sur 37,5 pondéré. Rang 6.

M-04 HTML multi-blocs (10 wp:html sectionnés)

Variante intelligente de M-03 : on découpe le HTML en N blocs Custom HTML, un par section.

Les sections deviennent déplaçables, dupliquables, supprimables dans l’éditeur Gutenberg. Le CSS reste centralisé dans la meta _uag_custom_page_level_css (ou tout autre canal d’injection CSS scopé page : Customizer, child theme, plugin Code Snippets).

Page live : methode-html-multiblocs. Compromis intéressant entre liberté design totale et éditabilité minimale.

• 10 blocs core/html sectionnés, CSS injecté page-level (meta Spectra ou Customizer ou child theme – au choix)
• Sections déplaçables, dupliquables dans l’éditeur
• Contenu d’une section reste opaque (HTML brut)
• Pour qui : sections à réorganiser sans toucher au design fin

Score : 22 sur 30 brut, 28,5 sur 37,5 pondéré. Rang 5.

M-05 Thème Spectra One (block theme + blocs Spectra)

Refaire la maquette en abandonnant Astra pour le thème Spectra One (gratuit, block theme moderne). Le design est assemblé avec les blocs Spectra natifs (advanced columns, advanced heading, container), sans une ligne de CSS personnalisé.

Page live : methode-spectra-pro. UI confortable, presets pertinents, édition WYSIWYG totale. Aucun abonnement payant requis pour cette version de la méthode.

Mais design "presets-driven" qui peine sur une charte fine. Et thème block-based plus lourd côté assets que Astra.

• Thème Spectra One (gratuit) à la place d’Astra
• 100 % blocs uagb/* (Spectra natif), paramètres via panels latéraux
• Pour qui : équipes WYSIWYG, sites sans charte fine, montée en compétence rapide
• Pas adapté : charte design fine, performance critique, automation scriptée

Score : 20 sur 30 brut, 25,5 sur 37,5 pondéré. Rang 6 ex-aequo.

M-06 Gutenberg pur + CSS dans 1 core/html (zéro plugin)

La variante 100 % native de M-02. Tout le design Direction B, sans aucune dépendance Spectra.

Le CSS (130 Ko) est embarqué dans un seul bloc core/html placé en tête de page, qui contient juste une balise <style> géante.

Le reste du contenu reste en vrais blocs Gutenberg natifs éditables. Page live : methode-gutenberg-pur. Spectra peut être désinstallé, le rendu reste identique à M-02.

• Markup blocs core/* éditables identiques à M-02
• CSS dans un seul bloc core/html en tête
• Aucun plugin requis, Spectra peut être désinstallé
• Pour qui : site indépendant, refus de toute dépendance plugin

Score : 26 sur 30 brut, 32,5 sur 37,5 pondéré. Rang 2.

M-07 Blocs PHP custom avec autoRegister WP 7.0 (ma préférence selon le contexte)

La méthode qui a fait basculer le verdict en mai 2026.

Un plugin custom wpf-lab déclare 11 blocs PHP, chacun avec un rendu serveur (render.php) et une UI d’édition auto-générée par WordPress 7.0 à partir du type de chaque attribut, via le flag supports.autoRegister.

Zéro JavaScript, zéro React, zéro build. Design 100 % verrouillé dans le plugin (un rédacteur ne peut pas casser le rendu). Édition champ par champ via la sidebar native Gutenberg.

Page live : methode-blocs-php-custom.

• Plugin custom wpf-lab v1.1.0 : 11 blocs PHP, 1 block.json plus 1 render.php par bloc
• Sidebar Gutenberg auto-générée par WP 7.0 (un champ par attribut)
• Markup post_content ultra-léger : 11 lignes, 3 Ko par page
• Compatible headless : render.php produit du HTML serveur exposable via REST sans transformation (voir mon guide migration headless WordPress)
• Pour qui : refonte marketing pro, design system rigoureux, équipe dev long-terme
• Pas adapté : réorganisation radicale par rédacteur, design différent par page

Score : 30 sur 30 brut, 37,5 sur 37,5 pondéré. Rang 1. Maximum sur tous les critères.

Matrice de scoring

Récapitulatif chiffré des 7 méthodes.

Méthode	C1 Édit	C2 Design	C3 Indép	C4 Repro	C5 Perf	C6 Maint	Brut /30	Pondéré /37,5
M-01 Gutenberg natif	5	2	5	5	5	3	25	29,5
M-02 Gutenberg + CSS perso	5	5	3	5	4	2	24	30,5
M-03 HTML monobloc	1	5	5	3	3	2	19	25,5
M-04 HTML multi-blocs	3	5	5	4	3	2	22	28,5
M-05 Spectra Pro	4	4	2	4	3	3	20	25,5
M-06 Gutenberg pur + core/html	5	5	5	5	3	3	26	32,5
M-07 Blocs PHP custom	5	5	5	5	5	5	30	37,5

Lecture rapide : seule M-07 obtient le maximum sur tous les critères.
M-06 est le seul autre à tenir 5 sur 5 en indépendance plugin tout en gardant la qualité visuelle.
M-02 (l’ancienne championne) reste très haut au cumul pondéré mais ne sort en tête sur aucun critère individuel.

Verdict par cas d’usage

La matrice donne le classement, mais le bon choix dépend du contexte. Voici comment j’arbitre selon le profil :

Votre profil ou besoin	Méthode recommandée	Pourquoi
Refonte WordPress 2026, équipe dev, design system rigoureux	M-07	Design verrouillé, édition champ par champ, versionnable Git, MAJ centralisée cross-pages
Site headless Next.js, Astro, Eleventy	M-07	render.php produit du HTML serveur exposable via REST sans transformation
Site indépendant, refus catégorique de tout plugin tiers	M-06	Pixel-conforme M-02 sans aucune dépendance plugin
Site existant en Gutenberg plus CSS personnalisé	M-02	Setup éprouvé, équipe interne déjà à l’aise avec le pattern
Section à réorganiser souvent par le rédacteur	M-04	Sections en blocs HTML déplaçables sans toucher au design fin
Landing one-shot livrée par graphiste, jamais retouchée	M-03	Design libre absolu, 1 fichier HTML, figé une bonne fois pour toutes
Équipe WYSIWYG, démarrage rapide, pas de besoin charte fine	M-05	Thème Spectra One gratuit plus blocs Spectra natifs : UI confortable pour non-codeurs
Formation WordPress débutants	M-01	Pédagogie : zéro CSS, juste les blocs core, pour comprendre Gutenberg avant tout

Focus M-07 : ce qui change avec WordPress 7.0

Le bascule du verdict est due à une nouveauté technique de WordPress 7.0 livrée le 20 mai 2026 : le pattern PHP-only block registration, annoncé par Miguel Fonseca dans la dev note officielle du 3 mars 2026 (ticket Trac #64639, implémentation par @priethor).

Pour comprendre l’impact, il faut rappeler les options qu’avaient les développeurs PHP avant.

• Payer ACF Pro : dépendance externe payante
• Apprendre React plus l’outillage wp-scripts : coût d’entrée élevé pour un dev PHP
• Blocs PHP register_block_type classiques : UI d’édition pauvre voire inexistante

WordPress 7.0 a livré un combo déclaratif qui change la donne. On déclare son bloc dans un block.json, on écrit le rendu serveur en PHP, et WordPress génère la sidebar d’édition automatiquement.

Le combo déclaratif

Pour qu’un bloc PHP reçoive son UI d’édition auto-générée, 2 conditions suffisent au niveau du block.json :

1. "supports": { "autoRegister": true } au niveau du bloc (un seul flag, pas par attribut)
2. Un rendu serveur fourni : soit "render": "file:./render.php" dans le block.json, soit un render_callback (closure PHP, qui est la forme utilisée dans l’exemple officiel de la dev note). Le combo autoRegister + render: "file:./render.php" est confirmé empiriquement sur les 8 pages live de ce benchmark.

WordPress lit le block.json, voit supports.autoRegister, et génère automatiquement les contrôles dans la sidebar Block à partir du type de chaque attribut : string donne un input texte, boolean donne un toggle, number donne un number input. Le rédacteur édite champ par champ via une UI WordPress native. À noter : les attributs avec le rôle local ou un type non supporté ne reçoivent pas de contrôle auto-généré (limite explicite de la dev note).

Code sample minimal

Le bloc wpf/lab-hero du plugin wpf-lab tient en 2 fichiers. Voici le block.json simplifié :

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "wpf/lab-hero",
  "title": "Lab Hero",
  "category": "wpf-lab",
  "supports": { "html": false, "autoRegister": true },
  "render": "file:./render.php",
  "attributes": {
    "titleStart":     { "type": "string", "default": "Methode 07 -" },
    "titleHighlight": { "type": "string", "default": "blocs PHP" },
    "titleEnd":       { "type": "string", "default": "x zero JS" },
    "lead":           { "type": "string", "default": "..." },
    "ctaPrimary":     { "type": "string", "default": "Voir section 2" }
  }
}

Et le render.php correspondant qui produit le markup serveur :

<?php
$titleStart     = $attributes['titleStart']     ?? 'Methode 07 -';
$titleHighlight = $attributes['titleHighlight'] ?? 'blocs PHP';
$titleEnd       = $attributes['titleEnd']       ?? 'x zero JS';
$lead           = $attributes['lead']           ?? '';
$ctaPrimary     = $attributes['ctaPrimary']     ?? 'Voir section 2';
?>
<section class="wpf-lab-hero">
  <h1 class="wpf-lab-hero__title">
    <?php echo esc_html( $titleStart ); ?>
    <span class="wpf-lab-hero__title-hl"><?php echo esc_html( $titleHighlight ); ?></span>
    <?php echo esc_html( $titleEnd ); ?>
  </h1>
  <p class="wpf-lab-hero__lead"><?php echo esc_html( $lead ); ?></p>
  <a href="#sec2" class="wpf-lab-btn"><?php echo esc_html( $ctaPrimary ); ?></a>
</section>

Dans la page, une seule ligne suffit : <!-- wp:wpf/lab-hero /-->. WordPress lit le render.php côté serveur et injecte le HTML. Échappement systématique via esc_html(), aucune surface XSS, aucune hydration React, aucun JS chargé en page.

La passe wow Direction B Lab

Pour démontrer jusqu’où on peut pousser la qualité visuelle, j’ai ajouté une couche d’effets CSS scopée à M-07. Shimmer permanent sur le mot acid du hero. Hovers spectaculaires sur les 4 piliers (élévation, ombre violet, bande acid révélée). Couronne violet pulsée sur la ligne M-07 de la matrice. Sweep lumineux sur les CTA.

Toutes les animations sont GPU-accelerated, gèrent prefers-reduced-motion, et se désactivent en mobile pour ne pas gêner le touch.

La passe wow ajoute 17 Ko de CSS. Aucun JavaScript, aucune image supplémentaire. Tout passe par transform, opacity, et des keyframes en cubic-bezier spring pour donner une sensation de "rebond naturel".

5 méthodes sur 7 dans le même site : le cas d’Alexandra

Le verdict de la matrice peut se lire comme un palmarès : M-07 sort en tête, donc on ferait M-07 partout. Sur un site réel, ça ne se passe pas du tout comme ça. Aucune des 7 méthodes ne s’utilise seule, et le bon site est celui qui sait composer.

Je vais l’illustrer avec Alexandra, la stagiaire graphiste numérique que j’évoque en intro de cet article. Elle est venue me voir pour monter en compétences WordPress + IA via ma formation WordPress sur-mesure et mener elle-même la refonte de son site : elle connaissait un peu WordPress mais pas suffisamment pour se lancer dans une véritable refonte. Je lui ai enseigné mon workflow WPFormation, à savoir piloter un site WordPress avec l’IA en co-développeur, et principalement Claude.

Le projet : site vitrine + boutique WooCommerce variable + bilingue FR/EN. Stack : Astra gratuit + thème enfant custom + Spectra + Polylang Pro + WooCommerce. Aucun page builder. Hébergement mutualisé O2switch. Dev solo. C’est Alexandra qui pilote son WordPress de bout en bout.

Son cas n’est pas isolé. La plupart de mes stagiaires sont dans cette situation : des personnes qui gèrent seules leur propre site WordPress, sans équipe derrière qui irait modifier régulièrement la page d’accueil. Le mapping qui suit s’applique à toute personne dans ce profil.

Le mapping zone par zone

Plutôt qu’une méthode unique appliquée partout, Alexandra a utilisé une technique différente par type de page, selon le besoin design, le besoin éditable et la fréquence de modification de chaque zone :

Zone du site	Technique retenue	Méthode du benchmark la plus proche
Pages vitrine éditoriales (Le Studio, Les Œuvres, L’Artiste)	Template PHP custom dans le child theme	M-03 / M-04 transposé au theme
Pages éditoriales fréquentes (Contact, FAQ)	Template PHP + the_content() avec blocs Spectra	M-05 light
Pages légales bilingues (Mentions, CGUV, Privacy)	Template PHP pur avec condition $lang	M-03 transposé + Polylang
Articles de blog	single.php natif + Gutenberg	Mix M-01 / M-02
Fiche produit WooCommerce	Templates WC + CSS scopé body.single-product	M-02 transposé au theme

Cinq méthodes du benchmark sur sept sont mobilisées sur le même site, chacune dans la zone où elle est la plus pertinente. C’est ça, composer : choisir selon le contexte de chaque zone, pas selon une recette unique. Une fiche produit WooCommerce ne se traite pas comme une page d’accueil éditoriale ; une FAQ qui bouge tous les mois ne se traite pas comme une page Artiste qui ne bougera jamais.

Le bon dosage : ce qu’on lock, ce qu’on laisse éditable

C’est la décision la plus structurante du projet, et celle que je transmets à toute personne qui pilote seule son site. Toutes les pages n’ont pas besoin d’être ultra-designées.

Les pages signature (l’accueil, les pages vitrine, les pages produit) sont verrouillées en PHP custom : c’est ce qui garantit le rendu pixel-perfect et un design qui ne dérive pas à la première modification. La FAQ, le Contact, les pages où le contenu bouge souvent vivent dans the_content() avec des blocs Spectra : deux clics dans l’admin WordPress et c’est modifié.

Le dosage n’est pas un arbitrage technique. C’est un arbitrage de praticité, qui dépend de deux variables seulement : la fréquence de modification et la nature du contenu (texte plat vs design complexe). Une FAQ qui bouge tous les mois mérite Spectra. Une page d’accueil au design tendu mérite le PHP custom.

Et pour Alexandra, le full PHP sur les pages signature n’est jamais un blocage. Quand elle a une modification à faire sur une de ces pages, même sans maîtriser le code à 100 %, elle ouvre Claude Code, elle décrit le changement, et c’est réglé en deux itérations. C’est le sens même de ce workflow : le code n’est plus un obstacle pour la personne qui pilote son site.

Les précautions qui transcendent la méthode

Au-dessus du choix de méthode par zone, six règles que je transmets à toute personne qui monte un site WordPress un peu complexe, quelle que soit la méthode retenue :

1. Versionner le child theme dans Git dès le premier commit. Convention type(scope): description.
2. Toujours un thème enfant. Aucune modification du thème parent (Astra ou autre).
3. Un design system unique : tokens CSS centralisés (tokens.css), prefix unique pour éviter toute collision avec Astra, Spectra et WordPress.
4. Enqueue CSS conditionnel : chaque feuille de style ne charge que sur la page qui en a besoin (is_page_template(), is_woocommerce()).
5. Snapshot fichiers + BDD avant chaque intervention en prod (JetBackup, UpdraftPlus ou équivalent) – c’est aussi le premier réflexe que je code dans toute maintenance WordPress mensuelle que je prends en charge.
6. Claude Code en co-développeur : brief texte, plan généré, validation, modification fichier local, upload, vérification en navigation privée, commit Git.

Ces règles ne dépendent pas du choix M-01 / M-02 / M-07. Elles transforment un site amateur en site professionnel, quelle que soit la méthode retenue zone par zone.

Petit aparté pour fermer cette section : la méthode M-07 que je présente comme ma préférence aujourd’hui n’était pas encore documentée au moment de la formation d’Alexandra. Son site est donc une photographie de l’état de l’art à l’instant où il a été construit. C’est vrai pour toute stack : elle reflète ce qu’on connaissait à l’époque, pas ce qui sortira trois mois après. La matrice de scoring fournit un vocabulaire ; le métier, c’est de composer avec ce vocabulaire, dans le bon contexte, au bon moment.

Claude.ai/Design : la voie qui tire vraiment vers le haut

Construire un site WordPress visuellement abouti en 2026, ce n’est plus une question de plugin AI builder. C’est une question de tooling design. Trois voies coexistent, mais une seule donne de loin les meilleurs résultats.

Les deux alternatives à connaître

Le skill frontend-design guide Claude Code vers les conventions d’un design system (tokens, palette, typo, espacements). Reproductible, versionnable. Le skill Impeccable (29 200 stars sur GitHub, par pbakaus, sous licence Apache 2.0) audite la qualité visuelle d’un rendu : alignement vertical, hiérarchie typographique, contraste. 23 commandes plus un CLI npx impeccable detect.

Ces 2 skills suffisent à dépasser le carcan "WP IA-généré conventionnel". Sont-ils mes outils de prédilection sur les vrais projets design ? Non. Je ne les utilise pas en parallèle de Claude.ai/Design. Je les mentionne ici parce qu’ils existent, parce qu’ils sont gratuits, et parce qu’ils répondent à des cas d’usage où l’on n’a pas accès au tier au-dessus.

Claude.ai/Design : de loin la meilleure voie

La research preview Anthropic Labs accessible aux abonnements Pro, Max, Team, Enterprise. Elle accepte un brief en langage naturel, des captures de référence, voire un dossier codebase complet. Le résultat est d’une autre catégorie : du design ultra soigné, pas "IA-générique". Exporte vers Canva, PDF, PPTX, HTML, ou directement vers un dossier prêt à être consommé par Claude Code.

Ce qui change vraiment, c’est la qualité du sample. frontend-design produit du correct. Claude.ai/Design produit du remarquable, pour peu qu’on sache l’utiliser. C’est un outil de Designer assisté par IA, pas un générateur de wireframes. Le brief doit être travaillé, les références précises, l’itération conversationnelle.

Mon workflow concret

• Phase 1 – Brief Claude.ai/Design dans le navigateur : intent métier, captures de référence, palette pressentie, contraintes (mobile-first, a11y, tokens existants). On itère par messages successifs, pas en un seul brief monstre.
• Phase 2 – Handoff : je récupère le HTML plus tokens depuis Claude.ai/Design et je l’amène dans Claude Code (via VSCode, pas en copier-coller dans le chat).
• Phase 3 – Transposition WP : Claude Code transpose vers l’éditeur WordPress (Gutenberg), soit avec mon skill astra-spectra (génération de blocs Gutenberg complets), soit avec le plugin wpf-lab de M-07 (blocs PHP custom avec autoRegister).

Pour qui ça change quelque chose ?

Les développeurs PHP et WordPress qui n’ont pas de Designer dédié : Claude.ai/Design leur donne accès à un niveau de design qui rivalise avec un sprint Figma ou une commande Webflow Studio. Les agences avec un Designer en interne : il accélère le brief et le sample initial, le Designer reste maître du sprint.

Maintenant qu’on a vu la voie qui change tout, voici ce que j’ai appris en me cassant la figure.

Anti-patterns rencontrés en cours de route

5 pièges techniques m’ont fait perdre du temps. Les noter ici évitera d’autres pertes à ceux qui reproduiront le protocole.

Piège 1 : la triche wp:html pour M-02 (détectée session 3)

Première itération, Claude Code avait embarqué toute la maquette dans un seul wp:html en prétendant que c’était M-02. La page rendait parfaitement côté front.

J’ouvre l’éditeur côté admin : du code partout, aucun bloc natif. La livraison passe à la poubelle, on recommence proprement.

Piège 2 : Tiger Protect o2switch et rate-limit 429

Découvert en plein pipeline de déploiement, à la 7e page poussée d’affilée. Sur les hébergements o2switch avec Tiger Protect actif, les écritures REST API rapides déclenchent un HTTP 429 "Too Many Requests".

Le pipeline s’arrête net. Aucune page de plus n’est acceptée pendant plusieurs minutes.

Piège 3 : zip Windows vs Unix-compat

Les zips créés avec PowerShell sur Windows utilisent les antislashes comme séparateurs internes. À l’extraction côté Linux/cPanel, la structure du plugin est cassée.

Résultat : le plugin est invisible après upload. Aucun message d’erreur explicite. On cherche pendant une demi-heure pourquoi WordPress n’affiche pas le nouveau plugin dans la liste.

Piège 4 : flèches Unicode rendues en emoji bleu Chromium

Sur les grands titres, Chromium remplace certaines flèches Unicode (les caractères ascendants et descendants) par leur version emoji color.

Sur une charte design en noir et acid, l’apparition d’une flèche bleue casse la typographie. Encore une heure perdue avant de comprendre l’origine du décalage visuel.

Piège 5 : Spectra Pro bascule en Code Editor sous Playwright

Lors des tests automatisés Playwright sur Spectra Pro, l’éditeur basculait parfois en "Code Editor" au lieu de l’éditeur visuel, sans clic explicite.

Limitation invisible en édition manuelle, fatale en automation. Documentée nulle part. Vous l’avez ici en premier.

Quatre façons d’aller plus loin

Pour continuer avec ce test ou en tirer parti sur votre projet :

• Voir le résultat : 8 URLs live sur test.wpformation.com (page HUB, M-01 à M-07). Comparaison visuelle directe, gelées 12 mois minimum.
• Télécharger le code : repo GitHub public wpformation/wpf-lab. Plugin wpf-lab complet, 11 blocs PHP, style.css 1158 lignes, scripts Node de déploiement. Licence open-source.
• Webinar live à venir : je rejoue l’intégralité du protocole en direct. Date calée selon l’intérêt, inscription via le formulaire ci-dessous.
• Formation sur-mesure : pour bâtir VOTRE propre plugin de blocs sur le même modèle, voir ma formation WordPress sur-mesure (OPCO éligible).

FAQ

Je débute avec WordPress, par où je commence ?

Par M-01 ou M-02. M-01 c’est Gutenberg pur, sans code, sans plugin tiers : ouvrez l’éditeur, posez vos blocs, publiez. C’est exactement ce que vous savez déjà faire ou apprendrez en quelques heures. M-02 ajoute une touche de design via un CSS personnalisé scopé à la page (champ texte dans l’éditeur, plugin Spectra gratuit). Pas de PHP, pas de React, pas de ligne de commande. Les méthodes M-03 à M-07 vous concerneront plus tard, quand vous voudrez aller plus loin ou que vous travaillerez avec un développeur. Commencez petit, livrez vite, vous monterez en compétence au fur et à mesure des projets.

Pourquoi WordPress 7.0 change la donne pour les blocs Gutenberg custom ?

Parce que le combo supports.autoRegister + un rendu serveur (render: "file:./render.php" dans le block.json, ou render_callback en closure PHP) permet pour la première fois d’écrire un bloc Gutenberg complet en PHP pur, avec UI d’édition native auto-générée à partir du type de chaque attribut, sans React, sans build. Avant WP 7.0, il fallait choisir entre payer ACF Pro, apprendre React, ou se contenter de blocs PHP à l’UI quasi-inexistante. Source officielle : la dev note PHP-only block registration du 3 mars 2026 (Miguel Fonseca, ticket Trac #64639).

Faut-il un plugin payant comme Spectra Pro pour faire un site WordPress moderne en 2026 ?

Non. Aucune des 7 méthodes testées ne nécessite Spectra Pro ni aucun autre plugin payant. M-02 et M-04 utilisent la version gratuite de Spectra pour bénéficier de sa meta _uag_custom_page_level_css (mais d’autres canaux d’injection CSS marchent aussi bien). M-01, M-03, M-06 et M-07 ne requièrent aucun plugin tiers. M-05 s’appuie sur le thème Spectra One gratuit avec les blocs Spectra natifs, pas sur Spectra Pro.

Est-ce que M-07 fonctionne sur un site headless Next.js ou Astro ?

Oui, et c’est l’un de ses gros avantages. Le render.php produit du HTML serveur propre, qui ressort tel quel via REST API (content.rendered). Un frontend Next.js, Astro ou Eleventy peut le consommer sans transformation, sans hydration React, sans block-renderer.js. Compatible nativement avec une architecture headless.

Combien de temps pour développer un plugin wpf-lab from scratch ?

Pour la structure de base (10 à 12 blocs PHP couvrant header, hero, sections de contenu, footer), comptez 1 à 2 journées d’un développeur PHP à l’aise avec WordPress. La courbe est essentiellement consacrée à la découpe en blocs et au CSS partagé. Chaque bloc tient en quelques dizaines de lignes : un block.json déclaratif plus un render.php avec esc_html(). La passe wow visuelle s’ajoute après, en CSS pur.

Pourquoi présenter 7 méthodes plutôt qu’une seule recommandation ?

Parce que la "bonne" méthode dépend du contexte. Un site historique déjà sur Spectra meta n’a aucune raison de migrer vers M-07 si M-02 fonctionne. Une agence avec licence Spectra Pro et équipe non-codeurs n’a pas à apprendre le PHP. Une formation débutants WordPress doit montrer le baseline natif M-01 avant tout. Notre rôle est d’éclairer la gamme, pas d’imposer une voie unique. Une fois la gamme maîtrisée, choisir devient évident.

Le sel et la force de WordPress restent intacts : éditabilité Gutenberg, REST API riche, écosystème de thèmes, déploiement simple. Ce qui change avec ces méthodes, c’est la qualité du design final.

Et la bonne nouvelle, c’est que la porte d’entrée reste ouverte. M-01 ne demande aucune compétence technique avancée. Vous pouvez livrer une première page propre dès cette semaine, puis monter en gamme progressivement vers M-02, M-06, M-07 selon vos projets et votre envie d’aller plus loin. Et si vous arrivez d’un page builder comme Elementor ou Divi, mon guide de migration vers Gutenberg prépare le terrain avant la nouvelle stack.