Comment j’ai migré 450 articles WordPress vers du headless avec Claude Code

Mon site était une ruine technique. Moi, Fabrice Ducarme – co-créateur de WPS Hide Login (plus de 2 millions d’installations actives), fondateur de WPServeur, speaker à 4 WordCamps, formateur WordPress certifié Qualiopi, dans l’écosystème WordPress depuis 2012. Et mon propre site n’avait pas bougé depuis 2012. Pas retouché. Pas redesigné. Pas même migré vers Gutenberg. Le cordonnier le plus mal chaussé de la communauté WordPress francophone.

Pendant trois ans, j’ai laissé WPFormation s’enliser. Un serveur dédié Dedibox surdimensionné, Cloudflare en façade pour masquer des temps de réponse qui n’en finissaient pas de grimper, 37 plugins actifs dont la moitié abandonnés, une base de données de 1,3 Go bouffée par des révisions jamais nettoyées, et un thème qui empilait du CSS custom comme on empile des post-it sur un bureau qu’on n’ose plus ranger. Le SEO partait en vrille, les positions s’effritaient, et chaque fois que je pensais"il faudrait s’en occuper", l’ampleur du chantier me décourageait.

En quatre jours – 27 commits, 15 à 18 heures de travail effectif – j’ai tout basculé sur une architecture headless WordPress + Next.js 16, avec Claude Code comme copilote. 345 articles migrés, zéro perte de contenu, zéro perte SEO. Score Lighthouse mobile : 98/100. Voici le retour d’expérience complet.

---

Le point de départ – le cordonnier le plus mal chaussé

Soyons honnête sur l’état des lieux… WPFormation, c’était un site qui fonctionnait malgré sa stack, pas grâce à elle.

L’éditeur classique. En 2026. Même pas Gutenberg. Le thème MKS, un format propriétaire que plus personne ne maintient depuis des années. L’éditeur WordPress que les débutants utilisaient en 2014. Sur le site d’un formateur WordPress. L’ironie ne m’a pas échappé.

Le diagnostic, froidement :

• 37 plugins actifs dont plusieurs abandonnés depuis des années
• 257 shortcodes [mks_button] éparpillés dans 22 articles – un format propriétaire lié à un thème mort
• 30 tableaux TablePress à migrer
• 1 348 Mo de base de données, gonflée par des années de révisions et de tables orphelines
• Score Lighthouse mobile : moins de 50 – pas de responsive digne de ce nom
• Un thème qui empilait les feuilles CSS custom sans aucune logique de composants

Le serveur ? Un dédié Dedibox chez Scaleway. Surdimensionné pour un blog, sous-optimisé pour le WordPress qu’il hébergeait. Cloudflare plaqué devant pour cacher les temps de réponse qui dépassaient la seconde. Quand il faut un CDN (Content Delivery Network – réseau de serveurs répartis dans le monde qui mettent en cache vos pages) pour rendre un blog WordPress à peu près utilisable, le problème n’est pas le réseau – c’est tout le reste…

Le SEO ? En chute libre. Les positions qui s’effritent mois après mois, le trafic organique en baisse, des Core Web Vitals dans le rouge. Normal : quand votre TTFB dépasse 800 ms et que votre page pèse 3 Mo de CSS non minifié, Google ne fait pas de cadeau. Même pas à un site qui parle de WordPress depuis 2012.

J’ai envisagé la refonte classique : nouveau thème, nettoyage plugin par plugin, optimisation progressive. J’ai même écrit un tutoriel complet sur la refonte WordPress il y a quelques années. Mais quand la dette technique atteint ce niveau, colmater les brèches revient à repeindre un mur porteur fissuré. Le problème n’était pas cosmétique – il était structurel.

La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.

Antoine de Saint-Exupéry

La question n’était plus"comment améliorer ce WordPress"mais"qu’est-ce que je garde et qu’est-ce que je jette".

Pourquoi le headless WordPress plutôt qu’un abandon pur et simple

Migrer vers un Webflow, un Ghost ou un autre CMS aurait signifié abandonner WordPress. Or WordPress reste, en 2026, le meilleur outil d’administration de contenu du marché pour un site éditorial. L’interface d’édition Gutenberg, la gestion des médias, les taxonomies, les custom fields, l’écosystème de plugins côté back-office – tout ça fonctionne. Ce qui pose problème, c’est le frontend PHP.

Mais concrètement, le headless WordPress, c’est quoi ? L’architecture headless WordPress consiste à découpler le back-office (WordPress) du frontend (ici Next.js). WordPress devient une API de contenu. On conserve l’interface d’administration qu’on connaît, on jette le moteur de rendu PHP, les thèmes et tout ce qui touche à l’affichage.

Concrètement, pour WPFormation :

La stack technique : Next.js 16 + WordPress API REST + Vercel

Le frontend repose sur Next.js 16 avec l’App Router – le standard moderne qui utilise le répertoire app/, les Server Components par défaut et generateStaticParams() pour la génération statique.

Pourquoi Next.js 16 spécifiquement ? Cette version apporte les Cache Components avec la directive"use cache", un système de cache explicite et opt-in qui remplace le cache implicite parfois imprévisible des versions précédentes de l’App Router. Les nouvelles API revalidateTag() et updateTag() offrent un contrôle fin sur l’invalidation du cache – exactement ce qu’il faut pour un CMS headless.

Le fonctionnement au quotidien est simple :

1. Au build, Next.js interroge l’API REST WordPress
2. Les pages sont pré-générées en HTML statique et déployées sur le CDN mondial de Vercel
3. Quand un visiteur arrive, il reçoit du HTML pré-rendu – pas de PHP, pas de requête base de données
4. Quand je publie un article, un webhook déclenche la revalidation ISR (Incremental Static Regeneration – le serveur regénère uniquement la page modifiée, sans reconstruire tout le site) – la page est régénérée en arrière-plan en 3 secondes

Les images passent automatiquement par le composant next/image qui gère la conversion WebP/AVIF, le lazy loading et le dimensionnement responsive. Plus besoin de plugin WordPress d’optimisation d’images – Next.js fait le travail nativement, et mieux.

L’architecture des URLs mérite une mention. Next.js 16 utilise generateStaticParams() pour définir quelles pages pré-générer. Pour WPFormation, ça signifie interroger l’API REST WordPress pour récupérer tous les slugs, puis générer le HTML correspondant :

// app/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await fetch(
    `${process.env.WORDPRESS_API_URL}/wp/v2/posts?per_page=100&_fields=slug`
  ).then(res => res.json())
  return posts.map(post => ({ slug: post.slug }))
}

Pour les données SEO, l’API REST WordPress avec Yoast expose un objet yoast_head_json sur chaque endpoint – title, description, Open Graph, canonical, le tout structuré en JSON, prêt à être injecté dans les balises <head> via generateMetadata() de Next.js.

Le coût d’hébergement du frontend : 20 dollars par mois sur le plan Pro de Vercel, qui inclut 1 To de bande passante. Le backend WordPress reste hébergé sur un mutualisé O2switch, délesté de tout le trafic frontend. Le coût total – frontend Vercel + backend O2switch – est inférieur à ce que coûtait le serveur dédié Dedibox seul.

Côté backend : 6 mu-plugins qui remplacent 34 plugins

C’est peut-être la partie la plus satisfaisante de cette migration. Plutôt que de garder des plugins classiques, j’ai écrit 6 mu-plugins sur mesure. Légers, sans interface d’administration inutile, chargés automatiquement par WordPress :

1. optimisation-wp – désactive les fonctionnalités inutiles du core (emojis, embed, pingbacks) et optimise les requêtes REST API. Ce que font 15 plugins en 80 lignes de PHP.
2. contact-form – un endpoint REST custom /wpf/v1/contact qui remplace Contact Form 7 et ses 500 Ko de JS. Rate limiting 5 req/h/IP, validation serveur, envoi email.
3. frontend-urls – réécriture automatique des URLs internes (domaine backend → domaine public) et prévisualisation des brouillons depuis le frontend Next.js.
4. auto-revalidate – le cœur du pipeline. À chaque publication, déclenche la revalidation ISR sur Vercel, puis ping IndexNow (Bing, Yandex, DuckDuckGo) et Google. Publier un article = 3 secondes pour que tout soit à jour.
5. security-hardening – XML-RPC désactivé, énumération des utilisateurs bloquée, triple couche noindex sur le backend (robots.txt + blog_public=0 + header HTTP). Le backend est invisible pour Google.
6. wpf-faq-schema – génération automatique du Schema FAQPage JSON-LD à partir des blocs FAQ natifs de Gutenberg. Les Rich Results Google apparaissent sans aucune configuration manuelle.

---

Claude Code, le copilote qui change tout

Claude Code n’est pas un chatbot à qui on demande des bouts de code à copier-coller. C’est un agent IA qui opère directement dans le terminal. Il lit le codebase, édite les fichiers, exécute des commandes, gère les commits Git – le tout en langage naturel…

Anthropic propose l’accès à Claude Code via plusieurs formules : le plan Pro à 20 $/mois inclut désormais l’accès terminal, le plan Max à 100 $/mois offre 5x la capacité d’usage, et le Max à 200 $/mois monte à 20x. Pour un projet de migration intensive comme celui-ci, le plan Max est un investissement rentable – on parle de quelques centaines de dollars pour un chantier qui aurait coûté des milliers en prestation.

Ma méthode de travail repose sur un principe simple : je suis l’architecte, Claude est l’exécutant. Je donne la direction stratégique, je définis les contraintes, je valide visuellement le résultat. Claude Code écrit le code, structure les composants, configure le déploiement, corrige les bugs.

L’outil ne fait pas le maître, mais le maître fait l’outil.

Yoda

L’itération est radicalement plus rapide qu’avec un développeur humain. Je dis"le header est trop chargé, simplifie" – Claude refait en 30 secondes."Le spacing entre les cartes d’articles n’est pas bon" – corrigé immédiatement. Pas de réunion, pas de brief de 10 pages, pas de ticket Jira. Le feedback est instantané et la boucle d’itération tient en quelques minutes.

Le fichier CLAUDE.md à la racine du projet sert de documentation vivante. Il contient les conventions de code, l’architecture choisie, les décisions prises et les bibliothèques autorisées. Claude Code le lit au démarrage de chaque session et s’y conforme :

# CLAUDE.md  -  WPFormation Next.js

## Architecture
- Next.js 16 App Router, Server Components par défaut
- WordPress REST API (pas GraphQL)
- Tailwind CSS pour le styling
- Déploiement Vercel, ISR avec revalidation on-demand

## Conventions
- Composants dans app/components/
- Utilitaires API dans lib/wordpress.ts
- Pas de"use client"sauf nécessité absolue (formulaires, interactivité)
- Images via next/image exclusivement

## Données WordPress
- Endpoint articles : /wp-json/wp/v2/posts
- Endpoint pages : /wp-json/wp/v2/pages
- Meta SEO via yoast_head_json

C’est l’équivalent d’un onboarding automatique – sauf qu’il fonctionne à chaque fois, sans oubli. La cohérence du code sur l’ensemble du projet en dépend directement.

Mais Claude Code va plus loin qu’un simple générateur de code. Pour ce projet, j’ai configuré 7 agents spécialisés :

• Un agent administration WordPress (serveur, plugins, BDD)
• Un agent design frontend (HTML/CSS → Next.js)
• Un agent contenu éditorial et un rédacteur anti-IA
• Un reviewer SEO qui audite chaque page sur 30 critères
• Un debugger et un auditeur design (responsive + accessibilité)

Chaque agent a son modèle (Opus pour le design complexe, Sonnet pour l’exécution rapide, Haiku pour les audits légers) et ses outils dédiés. Le résultat : une équipe virtuelle orchestrable depuis un terminal. Zéro clic dans une interface graphique. Je travaille dans mon IDE, Claude Code modifie les fichiers en direct.

---

Chronologie d’une migration en 4 jours

L’horodatage est précis : premier chantier le 20 février 2026, dernier commit le 23 février à 00h25. Quatre jours calendaires, 27 commits, entre 15 et 18 heures de travail effectif.

Jour 0 – jeudi 20 février : Migration serveur et grand nettoyage

Avant même de toucher au code, il fallait déménager. Le serveur dédié Dedibox était un luxe inutile – et un gouffre de maintenance. En architecture headless, le backend WordPress ne sert plus les visiteurs. Il répond aux requêtes API du frontend, point. Un mutualisé O2switch à 5 €/mois fait largement le travail.

Le package de migration pesait 5,9 Go. 264 tables MySQL, 11,6 millions de lignes. Douze ans d’accumulation, ça pèse…

• 70 tables orphelines supprimées – laissées par des plugins désinstallés depuis des années. Gain : 927 Mo.
• Sous-domaine dédié pour isoler le backend WordPress du frontend public, avec certificat SSL. L’administration est invisible – aucun visiteur n’y accède directement.
• Redirection 301 automatique – toute requête hors /wp-json/, /wp-admin/ et /wp-content/ renvoyée vers le frontend.

---

Jour 1 – vendredi 21 février : Audit et fondations (~1h30)

Session nocturne. L’objectif : nettoyer le terrain avant de construire.

Première opération : l’audit des 37 plugins. Avec Claude Code, j’ai analysé la dépendance réelle de chaque plugin. Résultat : 34 d’entre eux servaient exclusivement au frontend PHP ou étaient redondants. Désactivation et suppression. De 37 à 3 plugins – Astra Pro, WPS Hide Login et Yoast SEO. C’est tout.

Deuxième opération : le nettoyage BDD. Suppression des révisions accumulées sur 12 ans, des transients expirés, des tables orphelines, des commentaires spam. La base est passée de 1 348 Mo à 215 Mo, soit une réduction de 84 %. Ce n’est pas un nettoyage cosmétique – c’est le signe de l’ampleur du ballast accumulé.

Troisième opération : migration SEO. De Rank Math vers Yoast SEO. 485 entrées meta (title, description, Open Graph) transférées. Yoast expose ses données via l’API REST de façon plus standard que Rank Math, ce qui simplifie la consommation côté Next.js.

En parallèle : mise en place de l’infrastructure Claude Code – fichier CLAUDE.md, conventions de nommage, architecture app/ de Next.js 16.

---

Jour 2 – samedi 22 février : La grosse journée (~12-14h)

De 8h du matin à minuit, avec des pauses. C’est la journée où le site est né.

Le frontend complet, from scratch. Chaque page est un composant React Server Component qui interroge l’API REST WordPress. La homepage, les templates d’articles, les pages de catégories, les pages de formations, la page contact, une page 404 cosmique (parce qu’un détail comme ça fait la différence). Le tout stylé avec Tailwind CSS, un design system verrouillé – palette orange #FF8C00, typographies Inter Tight et Instrument Sans, composants responsive pensés pour la lisibilité.

La conversion des shortcodes. C’est le chantier le plus révélateur de la puissance de Claude Code sur du legacy WordPress. 257 instances de [mks_button] réparties dans 22 articles – un shortcode propriétaire du thème MKS. En headless, ces shortcodes ne sont plus interprétés : l’API REST renvoie le texte brut, pas le HTML rendu.

La solution : un script de migration via WP-CLI qui détecte les shortcodes par regex et les remplace par des blocs Gutenberg natifs. Claude Code a écrit le script, testé sur un échantillon, exécuté sur les 22 articles. Temps total : moins d’une heure.

Les 30 tableaux TablePress posaient un problème similaire. TablePress stocke ses données dans un custom post type séparé avec un shortcode [table id=XX]. En headless, rien ne s’affiche. La migration a consisté à extraire le HTML rendu de chaque tableau et l’insérer directement dans le contenu. Plus de dépendance au plugin – du HTML standard que l’API REST transmet sans traitement.

Les intégrations :

• Newsletter Brevo – composant React client avec double opt-in, sans transiter par WordPress
• Formulaire de contact – route API Next.js avec intégration CRM Brevo automatique
• CAPTCHA Cloudflare Turnstile – plus léger et moins intrusif que reCAPTCHA
• Google Analytics 4 – tracking client via next/script en stratégie lazyOnload

Chaque intégration fonctionne sans plugin WordPress – c’est du code Next.js natif, maintenable et versionné dans Git.

Les URLs. Suppression du préfixe /category/ pour des URLs aplaties. Trailing slash obligatoire partout – config Next.js, liens internes, canonicals, Schema.org. 102 redirections 301 des anciennes URLs. Ce genre de détail est critique pour une migration sans perte de trafic.

---

Jour 3 – dimanche 23 février : Pipeline et polish (~2-3h)

Dernière session nocturne. Le site fonctionne, il faut maintenant automatiser le workflow de publication.

Le pipeline de publication en 3 étapes automatiques :

1. Je publie dans WordPress → le mu-plugin auto-revalidate appelle le webhook Vercel
2. Vercel invalide le cache ISR de la page concernée → la page est régénérée en arrière-plan
3. IndexNow et Google sont notifiés en temps réel → les moteurs de recherche crawlent la page fraîche

Du clic sur"Publier"au site à jour : 3 secondes. Pas de build complet, pas de déploiement manuel.

Le workflow éditorial au quotidien. C’est la partie que personne n’explique dans les tutos headless. Comment on vit avec, au jour le jour ?

Je rédige dans Gutenberg. Blocs natifs uniquement – paragraphes, titres, images, listes, tableaux, citations, FAQ. La palette de couleurs WPFormation apparaît directement dans le sélecteur Gutenberg : un clic pour un fond sable sur un encadré conseil, un clic pour un fond orange doux sur un avertissement. Zéro shortcode à retenir. Zéro classe CSS à taper. Le même confort qu’un WordPress classique, la performance en plus.

Mon workflow au quotidien

1. J’écris dans WordPress – l’éditeur Gutenberg, les blocs natifs, exactement comme avant la migration. Rien n’a changé côté rédaction.
2. Je prévisualise sur le vrai site – un clic sur"Prévisualiser"dans WordPress ouvre l’article sur le frontend Next.js. Pas un aperçu approximatif dans un thème – le rendu final, avec les typographies, le responsive, les composants.
3. Je publie, c’est en ligne – un clic sur"Publier". Trois secondes plus tard, le site est à jour. Pas de commit. Pas de push. Pas de build. Le mu-plugin auto-revalidate s’en charge.

Je modifie, je prévisualise à nouveau. Je corrige une coquille, je mets à jour – c’est immédiat… Publier du contenu est devenu plus simple que sur un WordPress classique, parce qu’il n’y a plus de cache à vider, plus de plugin de minification à purger.

L’environnement local. Un npm run dev dans le terminal et j’ai le site complet en local, connecté à l’API WordPress. Je peux tester une nouvelle mise en page, modifier un composant, expérimenter un design – sans que rien ne touche au site en ligne. Quand c’est validé, un push. Quand ça ne convient pas, rien ne bouge. Ce filet de sécurité n’existe pas en WordPress classique, où chaque modification de thème est immédiatement live.

Le versioning Git. Tout le frontend est versionné sur GitHub. Branches, commits, pull requests, rollback en une commande. Si une mise à jour casse quelque chose, git revert et le site revient à l’état précédent en 30 secondes. J’utilisais déjà Git pour mes plugins WordPress et pour mes projets domotique. Mais sur WPFormation, le site éditorial, je n’en avais jamais eu l’usage. En headless, le code frontend EST le site. Le versionner devient une évidence.

L’optimisation images. Configuration fine de next/image pour la conversion automatique WebP/AVIF avec des breakpoints responsive adaptés aux usages réels. Les images servies depuis le CDN Vercel sont redimensionnées et compressées à la volée, avec un cache de 30 jours.

Le mode preview – comment ça marche en coulisses

Le bouton"Prévisualiser"de WordPress génère une URL de type /?p=1234&preview=true. En headless, cette URL pointe vers le backend – qui n’a plus de frontend PHP. Sur WPFormation, le flux de preview est reconstruit en trois étapes :

1. Un filtre PHP preview_post_link redirige le bouton vers une route API Next.js (/api/draft)
2. La route /api/draft active le Draft Mode de Next.js et récupère le brouillon via Basic Auth
3. La page article détecte le Draft Mode et affiche le brouillon avec une bannière orange

Détail technique : pourquoi un cookie plutôt que des searchParams pour transmettre le post_id au frontend ? Parce que les searchParams font partie de la clé de cache Vercel. Une URL avec ?post_id=1234 génère une entrée de cache différente de l’URL propre. Le cookie HTTP côté serveur est invisible au cache ISR – le brouillon s’affiche sans polluer le cache des visiteurs.

Le Schema.org. Données structurées sur chaque page :

• Article + BreadcrumbList + Person (E-E-A-T) sur chaque article
• Course + CourseInstance sur les pages formation
• Organization + EducationalOrganization + WebSite sur la homepage
• FAQPage sur les articles avec FAQ

Tests finaux. Vérification de chaque template, des 102 redirections 301, du sitemap XML, des données structurées. Audit des 375 liens internes – aucun cassé. Le 27ème et dernier commit clôt la migration.

---

Le piège SEO numéro 1 – le noindex du backend qui fuit sur le frontend

C’est le piège le plus dangereux de toute migration headless. Si tu rates ça, Google indexe deux versions de ton contenu – le frontend Next.js et le backend WordPress – et tu déchires ton autorité SEO en deux.

Sur WPFormation, on a mis en place une triple protection en couches. Pas un seul mécanisme – trois, parce qu’un seul peut être contourné.

Couche 1 : robots.txt sur le serveur backend

Le fichier robots.txt à la racine du sous-domaine backend bloque tous les crawlers avec un Disallow: / global. Première ligne de défense – simple, universellement compris. Mais pas suffisant seul.

Couche 2 : header HTTP X-Robots-Tag via mu-plugin

Un mu-plugin injecte un header HTTP X-Robots-Tag: noindex, nofollow sur toutes les réponses publiques WordPress. Contrairement au robots.txt, ce header est dans la réponse HTTP elle-même – impossible à ignorer pour un crawler sérieux.

// mu-plugins/wpf-backend-noindex.php
add_action('send_headers', function() {
    if (is_admin() || (defined('REST_REQUEST') && REST_REQUEST)) {
        return;
    }
    header('X-Robots-Tag: noindex, nofollow');
});

L’exclusion des requêtes REST_REQUEST est intentionnelle : on bloque les pages publiques (contenu dupliqué), pas les appels API (raison d’être du backend).

Couche 3 : blog_public=0 natif WordPress

Dans Réglages → Lecture, l’option"Demander aux moteurs de recherche de ne pas indexer ce site"est cochée. Cela positionne blog_public=0 et Yoast génère des balises noindex sur toutes les pages publiques. Trois couches, volontairement redondant.

Le sitemap : Yoast génère un sitemap côté WordPress – ne pas le soumettre à Google. Le sitemap à soumettre, c’est celui généré par Next.js via app/sitemap.ts. Deux propriétés Search Console distinctes : le frontend (principale, sitemap soumis ici) et le backend (surveillance uniquement – tout doit apparaître comme"bloqué par robots.txt"ou"noindex").

---

Le cockpit de monitoring – GSC, Analytics et positions dans le terminal

C’est la partie du setup qui a le plus changé ma façon de travailler. En mode headless avec Claude Code, le monitoring SEO ne passe plus par des tableaux de bord web – il passe par le terminal.

Le projet WPFormation dans Claude Code intègre des MCPs (Model Context Protocol) qui branchent directement Google Search Console et Google Analytics dans le terminal. Plus besoin d’ouvrir un navigateur pour vérifier les positions ou le trafic. On peut reprendre le contrôle de WordPress avec le MCP de manière radicale.

En pratique :"Analyse les articles entre les positions 4 et 15 avec plus de 100 impressions sur 30 jours."Claude Code interroge le MCP Search Console, retourne les données, identifie les articles en position"ventre mou" – et propose un plan d’action priorisé. L’audit SEO complet prend 10 à 15 minutes dans le terminal contre 2 à 3 heures de navigation entre tableaux de bord.

Pour le suivi de positions sur des mots-clés ciblés, j’utilise check-position.com – un SaaS français à 54 €/an pour 100 mots-clés. Claude Code croise les positions avec les données GSC, identifie les divergences, et produit un rapport synthétique. 83 monitors configurés, le tout pilotable depuis le terminal.

---

Les résultats – avant/après

Les chiffres parlent d’eux-mêmes.

Métrique	Avant	Après	Évolution
Plugins actifs	37	3	-92 %
Base de données	1 348 Mo	215 Mo	-84 %
Lighthouse mobile (Perf / A11y / BP / SEO)	< 50 / ? / ? / ?	98 / 97 / 100 / 100	quasi parfait
Lighthouse desktop	~60	100 / 96 / 100 / 100	100 en perf
Pages statiques (CDN)	0	~498	–
Temps de build	N/A	~30 secondes	Zero SSG
Coût hébergement total	~50 €/mois (dédié)	~25 €/mois	-50 %
Shortcodes propriétaires	257	0	éliminés
Tables TablePress	30	0 (HTML natif)	éliminées
TTFB	> 800 ms	< 50 ms	-94 %

Le score Lighthouse n’est pas un exploit isolé sur une page test – c’est le score moyen sur l’ensemble du site. Les Core Web Vitals sont dans le vert : LCP sous les 2,5 secondes, CLS quasi nul, INP excellent puisque le gros du site est du HTML statique sans JavaScript lourd.

Pour mettre ça en perspective : obtenir un score PageSpeed de 100/100 sur WordPress classique demande des heures d’optimisation – cache, minification, lazy loading, CDN, nettoyage CSS. En headless avec Next.js, le score de 98+ est presque un effet secondaire de l’architecture elle-même. Le HTML statique est léger par nature. Les images sont optimisées nativement. Le JavaScript côté client est minimal.

Côté SEO, les 345+ articles ont conservé leurs URLs, leurs meta titles et descriptions, leurs données structurées. Google a re-crawlé le site sans erreur de couverture dans la Search Console. Le trafic organique n’a pas bougé – ce qui, pour une migration de cette ampleur, est exactement le résultat visé. L’indexation des nouvelles URLs s’est faite en quelques jours grâce aux pings IndexNow automatiques.

---

Ce que j’ai appris – et ce que je referais différemment

L’IA amplifie l’expertise, elle ne la remplace pas

C’est la leçon centrale de cette migration. Claude Code est un exécutant bluffant – rapide, infatigable, capable de produire du code fonctionnel dans des dizaines de contextes. Mais il ne prend pas de décisions architecturales. Il ne sait pas qu’il faut migrer de Rank Math vers Yoast parce que l’API REST est mieux structurée. Il ne devine pas qu’il faut aplatir les URLs de catégories pour le SEO.

Sans mes 15 ans de WordPress derrière moi – la connaissance des hooks, de la structure de la base de données, des conventions de l’écosystème, l’expérience de plugins installés sur des millions de sites – Claude Code aurait produit un joli site Next.js générique. Avec cette expertise, on a produit un site qui respecte les subtilités d’un écosystème éditorial construit sur 12 ans.

Expertise du domaine + IA d’exécution = résultat qu’aucun des deux n’aurait atteint seul. Un développeur Next.js junior avec Claude Code n’aurait pas su quoi demander. Un expert WordPress sans Claude Code aurait mis des semaines, voire des mois.

Ce que je referais différemment

• La migration des meta SEO aurait dû être scriptée en amont. J’ai fait la migration Rank Math → Yoast pendant le chantier, mais un script WP-CLI préparé quelques jours avant aurait rendu l’opération plus propre.
• Documenter chaque prompt Claude Code significatif. Pas pour reproduire la migration à l’identique, mais pour constituer une bibliothèque de patterns :"comment convertir les shortcodes","comment configurer l’ISR avec l’API REST WordPress".
• Anticiper la prévisualisation éditoriale dès le jour 1. En headless, le bouton"Prévisualiser"de WordPress ne fonctionne plus nativement. Il faut un mode preview dans Next.js. C’est fait, mais j’aurais pu le planifier plus tôt.

Points de vigilance pour toute migration headless

Le workflow éditorial change. Un rédacteur habitué au WYSIWYG perd cette immédiateté. Pour un site solo, c’est anecdotique. Pour une équipe de 10 personnes, c’est un point de friction à anticiper.

Certains plugins WordPress n’ont aucun sens en mode headless. Tout ce qui touche au frontend (builders, cache, formulaires) disparaît. C’est un avantage (moins de maintenance) mais il faut reconstruire les fonctionnalités côté Next.js. Formulaire de contact, newsletter, CAPTCHA – tout a été recodé.

Les sitemaps XML doivent être générés côté Next.js, pas côté WordPress. Yoast continue de générer un sitemap, mais c’est celui du frontend qui doit être soumis à Google.

FAQ – WordPress headless et Claude Code

Combien coûte une migration WordPress headless avec Next.js ?

Pour la migration de WPFormation (345 articles) : environ 200 $ d’abonnement Claude Code (plan Max, 1 mois) + 20 $/mois d’hébergement Vercel Pro + l’hébergement WordPress existant. Total hors temps humain : moins de 250 $. En agence, une refonte similaire se facture entre 5 000 et 30 000 € avec 2 à 8 semaines de délai. Le prérequis : l’expertise technique pour piloter l’IA.

Le headless WordPress avec Next.js casse-t-il le SEO ?

Non, à condition de gérer trois points : le noindex du backend (triple protection : robots.txt + header X-Robots-Tag + blog_public=0), le sitemap généré côté Next.js (pas côté WordPress), et l’override du noindex dans generateMetadata() côté frontend. Sur WPFormation, le trafic organique n’a pas bougé après la migration.

Faut-il utiliser GraphQL ou l’API REST WordPress ?

Pour un site éditorial comme un blog ou un magazine, l’API REST native suffit. Elle est intégrée au core WordPress depuis la version 4.7 – zéro plugin à installer. GraphQL via WPGraphQL brille pour les requêtes complexes imbriquées. Pour WPFormation, les endpoints REST couvrent 95 % des besoins. Chaque plugin en moins, c’est une surface d’attaque réduite.

Le headless WordPress est-il adapté à un blog ?

C’est même le cas d’usage idéal. Un blog est un site de contenu statique par nature – les articles ne changent pas entre deux visites. L’ISR de Next.js génère le HTML une fois, le sert depuis un CDN mondial, le régénère uniquement quand le contenu change. Résultat : un TTFB de moins de 50 ms au lieu de 800+ ms en PHP. Le headless n’est PAS adapté si votre blog dépend d’un builder visuel (Elementor, Divi) ou si vous n’avez aucune compétence JavaScript.

Claude Code peut-il remplacer un développeur ?

Non. Claude Code est un exécutant, pas un architecte. Sans expertise métier pour le guider, il produit du code générique. La vraie formule : un expert qui sait exactement quoi demander + Claude Code qui exécute à une vitesse surhumaine. Le goulot d’étranglement n’est plus"combien de temps pour coder ça"mais"est-ce que je sais quoi demander".

Comment fonctionne le mode preview en WordPress headless ?

Le bouton"Prévisualiser"de WordPress est redirigé via un filtre PHP vers une route API Next.js qui active le Draft Mode. Le brouillon est récupéré via Basic Auth et affiché avec une bannière de prévisualisation. Un cookie HTTP transmet le post_id sans polluer le cache ISR de Vercel. Une fois configuré, le workflow éditorial est transparent pour le rédacteur.

Quels plugins WordPress garder en mode headless ?

Le strict minimum. Pour WPFormation : Astra Pro (thème admin), Yoast SEO (meta via API REST) et quelques mu-plugins sur mesure. Tout le reste – cache frontend, minification, formulaires, sliders, builders – n’a plus de raison d’exister. Les fonctionnalités manquantes sont reconstruites en mu-plugins PHP de moins de 500 lignes au total.

Peut-on revenir en arrière après une migration headless ?

Techniquement oui – le backend WordPress est intact. Réactiver un thème PHP et désactiver les configurations headless suffit. En pratique, une fois les formulaires, le preview et les intégrations réécrits en Next.js, le retour arrière représente un travail significatif. C’est une décision à peser sérieusement.

Combien de temps prend une migration WordPress vers headless Next.js ?

Sur WPFormation (345 articles, 37 plugins, 12 ans d’historique), 4 jours – 15 à 18 heures de travail effectif avec Claude Code. Sans IA, compter 2 à 8 semaines pour un site de complexité similaire. Le facteur déterminant : le nombre de shortcodes et de plugins à remplacer, pas le nombre d’articles.

---

WordPress headless avec Claude Code – pour qui ?

Cette approche n’est pas universelle.

Les profils qui en tireront le maximum :

• Les développeurs WordPress expérimentés qui connaissent l’API REST et les rouages du CMS
• Les agences techniques qui veulent proposer des sites ultra-performants sans abandonner WordPress côté client
• Les sites à fort volume de contenu (blogs, médias, documentation) où la performance est un enjeu business

Les profils pour qui c’est prématuré :

• Les utilisateurs WordPress qui dépendent de builders visuels (Elementor, Divi) – le headless élimine cette couche
• Les petits sites vitrines de 5-10 pages où un bon thème optimisé suffit
• Les équipes sans compétence JavaScript/React côté frontend

Et soyons clairs : si votre WordPress actuel fonctionne bien, que vos scores Lighthouse sont corrects et que votre stack ne croule pas sous la dette technique, le headless n’est pas un objectif en soi. C’est une solution à un problème précis, pas une mode à suivre.

Le coût total réaliste d’une migration similaire :

Poste	Coût
Abonnement Claude Code (Max, 1 mois)	100-200 $
Hébergement frontend (Vercel Pro)	20 $/mois
Hébergement WordPress backend (O2switch)	~5 €/mois
Nom de domaine, DNS	Existant
Temps humain (15-18h d’expertise)	Variable
Total hors temps humain	~150-250 $

Comparé au coût d’une refonte par une agence – entre 5 000 et 30 000 €, 2 à 8 semaines de délai – l’économie est vertigineuse… Mais elle repose sur un prérequis non négociable : l’expertise technique pour piloter l’IA.

---

Et maintenant

Le headless WordPress piloté par IA n’est plus un projet de 6 mois facturé 50 000 €. C’est un week-end intense pour qui maîtrise son sujet. Quatre jours, 27 commits, un site qui passe de Lighthouse 50 à 98, une base de données allégée de 84 %, un frontend servi depuis un CDN mondial pour 20 $/mois.

Ce qui a changé, ce n’est pas WordPress – c’est la vitesse d’exécution. Avec Claude Code dans le terminal, le goulot d’étranglement n’est plus"combien de temps pour coder ça"mais"est-ce que je sais exactement quoi demander". L’expertise humaine devient le multiplicateur. L’IA est le moteur.

On entre dans une ère où le profil le plus redoutable sur le marché n’est pas le développeur le plus rapide ni l’expert le plus pointu – c’est celui qui combine les deux. Un expert métier capable d’orchestrer des agents IA produit en un week-end ce qu’une équipe de trois personnes livrait en un mois. Ça change la donne pour les freelances, les formateurs, les créateurs de contenu technique qui ont 10 ou 20 ans de terrain derrière eux. J’ai d’ailleurs appliqué une approche similaire pour reconstruire un site institutionnel en 5 jours avec Next.js et l’IA – même principe, autre contexte.

WPFormation tourne désormais sur une architecture qui peut encaisser les 10 prochaines années sans accumuler la dette technique des 12 précédentes. Et si demain je veux changer de framework frontend – passer de Next.js à Astro, ou à ce qui émergera – le backend WordPress reste intact. C’est toute la puissance du découplage.

Et honnêtement ? Je me suis éclaté. Je ne m’y attendais pas. Après trois ans à regarder WPFormation se dégrader sans oser y toucher, je m’attendais à un chantier pénible, un mal nécessaire. C’est tout l’inverse qui s’est passé. L’itération avec Claude Code est addictive : tu vois le résultat en temps réel, tu ajustes, ça avance à une vitesse qui te fait sourire. La satisfaction de voir un score Lighthouse passer de 48 à 98. De voir le TTFB tomber sous les 50 ms. De supprimer 34 plugins d’un coup et de constater que tout marche mieux sans eux. Ce n’était pas du travail. C’était du jeu. Du vrai plaisir de créateur, celui qu’on a quand on construit quelque chose et que ça fonctionne pile comme on l’imaginait.

Le chantier n’est pas terminé pour autant. 345 articles migrés, c’est fait. Mais 12 ans de contenu, ça laisse des traces : 140 articles orphelins à relier par du maillage interne, une centaine d’articles à rafraîchir (contenu obsolète mais à fort potentiel), un travail d’optimisation GEO pour les moteurs IA qui commence tout juste. Le site est le laboratoire. Chaque semaine, je teste, j’itère, je documente. Et je publie ici ce que j’apprends.

Le meilleur moment pour planter un arbre, c’était il y a vingt ans. Le deuxième meilleur moment, c’est maintenant.

Proverbe chinois

La vraie question n’est plus"faut-il passer au headless"mais"est-ce que vous avez l’expertise pour en tirer parti". Si la réponse est oui, il n’y a plus aucune raison d’attendre.