WordPress headless, 7 mois en production : mes chiffres sans filtre

En mars, j’ai écrit que mon site répondait en moins de 50 millisecondes. C’était vrai… dans le laboratoire de Google. Chez mes visiteurs, sur mobile, la première réponse du serveur arrive en 450 millisecondes.

Je vous dois donc un bilan sans filtre. Celui d’un site éditorial de 346 articles qui tourne en production depuis le 22 février, avec ses factures, ses incidents datés, la liste de tout ce que j’ai dû reconstruire à la main, et ce que les aperçus IA de Google ont changé à mon trafic depuis l’été.

Une précision avant d’entrer dans les chiffres : je ne publie pas mes volumes de clics. Vous trouverez ici des évolutions en pourcentage, toujours comparées aux mêmes jours de l’année précédente, ce qui suffit pour juger d’une tendance.

De la bascule, je garde un souvenir en trois temps : l’excitation de la nouvelle techno, puis les regrets et les doutes, puis enfin le soulagement, une fois que tout est revenu à la normale. Le soulagement a tenu. Les doutes aussi, un peu, et ils m’ont obligé à tout mesurer.

Mon avis, après sept mois : le headless tient ses promesses de performance, de sécurité et de liberté de design. En échange, il m’a demandé beaucoup d’apprentissage et un travail de construction permanent, semé de pièges que personne ne documente. Et pourtant, aujourd’hui, je prends un vrai plaisir à m’en servir, maintenant que je la maîtrise et que Claude Code m’assiste.

Ce qui tourne où : mon site en un schéma

Jusqu’en février, wpformation.com était un WordPress classique : un thème, 37 extensions, WP Rocket pour le cache, le tout sur un serveur dédié à 89 € par mois. Le même logiciel écrivait les articles et les servait aux visiteurs.

Aujourd’hui, le travail est coupé en deux. WordPress ne sert plus que de back-office : j’y écris, j’y range mes images, et Yoast y calcule toujours mes titres et mes descriptions. Il tourne chez Hetzner depuis le 31 mai, sur un serveur que je partage avec d’autres projets. Personne ne le visite : ses pages publiques renvoient en redirection 301 vers wpformation.com, et il est fermé à l’indexation.

Le site que vous lisez est une application Next.js, hébergée chez Vercel. Elle interroge l’API REST de WordPress, fabrique chaque page une fois, la garde en cache et la resert telle quelle pendant une heure. Quand je publie, WordPress prévient le site par un webhook, et le site jette puis refait seulement ce qui a changé : l’article, l’accueil, le plan du site, le flux RSS, les fichiers llms.txt et les catégories concernées.

Pour Google, rien ne change en apparence : chaque page arrive en HTML complet, déjà assemblée sur le serveur, avec ses balises Yoast, son plan du site et ses données structurées. Un robot qui n’exécute pas JavaScript lit exactement ce que lit un visiteur.

Et il y a un troisième public, que je n’avais pas vraiment en tête en février : les agents IA. Ils ont leurs propres portes d’entrée. Un fichier llms.txt qui résume le site, une version Markdown de chaque article servie à ceux qui la demandent, et un serveur MCP public qui laisse un assistant chercher dans mes articles ou vérifier la santé d’une extension. Ces portes, je les ai codées en quelques soirées, parce que le site public est une application et que je n’avais aucun thème à contourner.

Tout n’est pas encore à sa place définitive… Un petit serveur Hetzner attend de remplacer Vercel pour le site public : j’y reviens plus bas, factures à l’appui.

Mes chiffres de mars tenaient-ils face aux visiteurs ?

Dans mon retour d’expérience sur la migration, j’annonçais un temps de réponse du serveur passé de plus de 800 ms à moins de 50, et un score Lighthouse de 98 sur 100. Ces mesures sortaient d’outils de laboratoire : une visite simulée, lancée depuis les serveurs de Google, sur un mobile volontairement bridé.

Mes visiteurs, eux, ne vivent pas dans un laboratoire. Chrome remonte leurs mesures réelles dans son rapport d’expérience utilisateur (CrUX), sur 28 jours glissants. Sur la période close le 22 septembre, pour trois visiteurs sur quatre, la première réponse du serveur arrive en moins de 450 ms sur mobile et de 295 ms sur ordinateur.

Le laboratoire se trompe en effet dans les deux sens. Pour la réponse du serveur, il est trop optimiste. Pour l’affichage du contenu principal (le LCP), il est trop sévère : 2,4 secondes simulées, contre 1,8 seconde chez les vrais visiteurs mobiles.

Les trois indicateurs de Google restent dans le vert, avec un LCP sous les 2,5 secondes, une réactivité (INP) de 126 ms et une stabilité visuelle parfaite. Et ils n’ont presque pas bougé depuis avril, date des plus anciennes mesures que Chrome me donne : 1,77 seconde d’affichage sur mobile à l’époque, 1,83 aujourd’hui.

Alors, le headless est-il plus rapide ? Je le pense toujours, et je le vis au quotidien : la performance est clairement meilleure qu’avec un WordPress classique.

Toutefois, je vous dois un chiffre qui me gêne. Il n’existe qu’une seule mesure de terrain de l’ancien site, relevée par un audit le 22 février sur les 28 jours précédents, donc surtout sur l’ancien WordPress : sur ordinateur, un LCP de 1,0 seconde. Aujourd’hui, mes visiteurs sur ordinateur sont à 1,35 seconde.

La preuve est fragile : un outil tiers, pas de capture brute. Elle suffit pourtant à me faire lever le pied sur les grandes promesses. Mon ancien site plafonnait sous les 50 en laboratoire sur mobile, sans être forcément lent pour ceux qui le lisaient sur ordinateur. J’ai d’ailleurs ajouté ces chiffres de terrain, datés, dans l’article de migration.

Le trafic Google, à mois égaux

En juin, un de mes rapports annonçait +76 % de clics. Il comparait l’automne 2025, creux de l’été compris, au printemps 2026. Même site, même outil, et un chiffre sept fois trop beau. Depuis, je compare toujours les mêmes jours d’une année sur l’autre, décalés de 364 jours pour garder les mêmes jours de la semaine.

Avec cette règle, voici ce que donne Search Console, en recherche web :

Période de 2026	Clics	Affichages dans Google
5 janvier au 21 février (l’ancien site)	-33 %	+3 %
Mars à mai	+11 %	-26 %
1er juin au 21 juillet	+25 %	-20 %
22 juillet au 31 août	+2 %	-1 %
1er au 26 septembre	-22 %	+7 %

En janvier et février, l’ancien site s’essoufflait : un tiers de clics en moins que l’année précédente, pour autant d’affichages. Puis, à partir de la fin mars, la courbe repasse au-dessus de 2025 et y reste presque sans interruption jusqu’à la mi-août, avec une pointe à +43 % la semaine du 18 mai.

Le détail le plus intéressant se cache dans la dernière colonne. Au printemps, mes pages se sont affichées 26 % moins souvent qu’en 2025, et j’ai pourtant récolté plus de clics : le taux de clic est passé de 1,16 % à 1,75 %.

L’été s’est tenu à égalité avec 2025. Septembre, en revanche, est franchement dur : 22 % de clics en moins que les mêmes jours de l’an dernier, alors que mes pages s’affichent 7 % plus souvent. Plus visible, moins cliqué… cette signature a une cause, et elle mérite sa propre section.

Je ne m’attribue pas tout, ni dans un sens ni dans l’autre. Entre-temps, j’ai supprimé une centaine d’articles morts (le site est passé d’environ 450 à moins de 350 articles), retravaillé des contenus, et le reste du web a bougé. Le headless a surtout rendu ces chantiers rapides. Sa part exacte dans la progression du printemps, je ne sais pas l’isoler, et je me méfie de ceux qui prétendent le faire.

Depuis la bascule, sur l’ensemble de la période, le bilan reste positif : +9 % de clics, avec 17 % d’affichages en moins. La bascule elle-même n’a pas fait décrocher le trafic.

Aperçus IA de Google : plus visible, moins cliqué

Le 22 juillet, Google a ouvert ses aperçus IA (les AI Overviews) en France : ces réponses rédigées par son IA, en tête de page, qui citent quelques sources en lien. J’avais préparé le terrain dans mon article sur le zéro clic et les aperçus IA. Restait à voir ce que ça donnerait sur mon propre site.

Search Console a ajouté un rapport pour le mesurer, encore en bêta, baptisé "Fonctionnalités d’IA générative". Il compte les fois où mes pages apparaissent dans ces réponses. Entre début juillet et septembre, ces affichages ont été multipliés par cinq. La montée démarre la semaine du 22 juillet, puis plafonne depuis la mi-août. Sur les quatre dernières semaines, ils représentent 14 % de tous les affichages de mes pages dans Google, à peu près un sur sept.

Les pages que l’IA de Google montre le plus ne sont pas celles que j’attendais. En tête : mon comparatif d’hébergeurs WordPress, mon guide pour réparer un WordPress piraté, ma checklist SEO et mon tutoriel pour connecter Claude à WordPress par MCP. Deux d’entre elles existent depuis 2016, remises à jour au fil des ans, et aucune ne parle de headless. Ces quatre pages ne pèsent pourtant que 18 % du total : l’IA de Google puise dans plus de 450 adresses de mon site.

Près des trois quarts de ces affichages (73 %) viennent de France. Et 91 % se font sur ordinateur, contre 80 % pour l’ensemble de mes affichages dans Google : mon public cherche surtout depuis un bureau, et c’est encore plus net dans les réponses de l’IA.

Sur la requête "wordpress headless", j’ai vérifié ce 29 septembre, depuis la France : mon guide est premier dans les résultats classiques, et première des cinq sources citées par l’aperçu IA. Je suis aussi 200 requêtes au quotidien avec Monitorank. Le 28 septembre, 174 d’entre elles affichaient un aperçu IA (87 %), et mon site était cité dans 55 % de ces aperçus. Un seul relevé par jour, sur des requêtes que j’ai choisies moi-même : je le lis comme une tendance, et je me garde d’en faire une mesure du web entier.

La facture, en clics

Voici la face moins drôle. Fin juillet et début août, en France, sur deux semaines comparées aux deux semaines d’avant le 22 juillet, mes pages se sont affichées 24 % plus souvent… et ont reçu 35 % de clics en moins. Le taux de clic a presque été divisé par deux (-47 %), et ma position moyenne a reculé de 9,9 à 13,4. L’encadré de l’IA, placé au-dessus, pousse les résultats classiques vers le bas de la page, mais mes chiffres agrégés ne disent pas quelle part de ce recul lui revient.

L’été explique une partie du recul, pas tout. La même quinzaine de 2025, sans aperçu IA, avait perdu 18 % de clics, avec un taux de clic à peine en baisse (-8 %). Et sur la même période de 2026, mon taux de clic a progressé en Belgique (+18 %) et au Canada (+26 %), et il est resté stable en Suisse. La chute est bel et bien française.

Septembre creuse l’écart. D’habitude, la rentrée ramène les clics : en 2025, mon taux de clic français avait bondi de 69 % entre la mi-juillet et la mi-septembre. Cette année, sur les mêmes semaines, il recule de 39 %.

Et les assistants comme ChatGPT ou Perplexity ? Ils m’envoient entre 1 et 1,6 % de mes visites mesurées chaque mois depuis mars, sans progression. ChatGPT, Perplexity, Claude, Gemini, Copilot et Mistral réunis. Être cité ne veut pas dire être visité.

Ma lecture : une bonne chose, à condition de s’adapter

Pour autant, je trouve que c’est une bonne chose. À titre personnel, je gagne en visibilité et je perds des clics. J’estime qu’il faut vivre avec son temps : à l’ère de l’IA, les gens vont chercher de cette façon. Et de toute façon, Google est un acteur tellement important qu’il peut décider ce qu’il veut. On doit s’adapter.

Pour moi, s’adapter veut dire prévoir un référencement à 360°. Ne plus me contenter du seul site, mais être présent aussi sur les réseaux sociaux, et en vidéo, sur YouTube par exemple. Le site reste la base, celle que l’IA cite ; ce sont les autres canaux qui ramènent les gens jusqu’à moi quand le clic se raréfie.

Le headless m’aide-t-il à être cité ? Je n’en suis pas certain. Je pense qu’il aide surtout à démontrer que mon site est performant, et qu’il respecte bien les recommandations de Google sur les Core Web Vitals. Rien, dans mes chiffres, ne me permet de dire que mon guide sort premier sur "wordpress headless" parce qu’il est servi par Next.js.

En revanche, la version Markdown de chaque article et le serveur MCP public sont des briques qui peuvent potentiellement m’aider. En tout cas, elles permettent aux IA de mieux comprendre mes contenus et mon site. Je les détaille, avec le reste de ma démarche, dans mon guide sur l’optimisation d’un WordPress pour les moteurs IA. Mais je reste, malgré tout, persuadé que c’est le contenu qui fait le principal.

Des demandes, enfin

Le changement qui compte le plus ne se voit pas dans Search Console. En 2025, le site était totalement amorphe : je n’avais quasiment plus aucune demande, une par trimestre, de mémoire. Autant dire rien.

Depuis la refonte, mon formulaire de contact a reçu au moins 58 demandes en sept mois, dont 41 pour de la formation, de la maintenance, de l’expertise ou de l’accompagnement. Certaines semaines, j’en reçois quatre. "Au moins", parce que ma boîte mail a des trous et que je ne compte ni LinkedIn, ni le téléphone, ni les recommandations, ni les courriels directs.

Ce qui compte, c’est d’obtenir la demande, pas forcément de signer le devis. À partir du moment où j’ai des leads, c’est que quelque part mon site est performant. Ensuite, ma négociation fait la différence.

J’accepte ces demandes, ou pas, au cas par cas et selon la complexité du projet. Le seul projet headless arrivé par le formulaire, un site de presse avec abonnements payants, je l’ai refusé : je l’estimais trop complexe pour un seul individu.

Est-ce grâce au headless ? Honnêtement, la refonte a surtout changé les choses, avec ma manière de présenter WPFormation. La technique a rendu le reste possible : les outils gratuits et les pages de services, sur un site qui charge vite et que je modifie en une soirée.

Tout ce que WordPress faisait seul, et que j’ai dû refaire

C’est le piège dont je préviens en premier un confrère qui veut passer en headless : ça va être un peu du travail. Tous les plugins qu’on utilise habituellement, il faut absolument les refaire ou les retravailler, et prévoir le temps qui va avec.

Un WordPress classique rend une foule de services sans qu’on y pense. Dès qu’un autre logiciel affiche le site, chacun devient du code à écrire, à tester et à surveiller. Voici ma liste réelle, tirée du code de wpformation.com :

Fonction	Avec un WordPress classique	Sur mon site headless
Titre, description, balises robots, données structurées	Yoast les écrit dans la page	Le site relit ce que Yoast calcule, par l’API, plus un point d’accès maison et un module pour les FAQ
Plan du site et robots.txt	Générés d’office	Deux routes codées, sous contrôle quotidien depuis avril
Redirections	Une extension	661 entrées dans le code, un déploiement à chaque ajout
Pages introuvables	Une vraie erreur 404	À coder, et à vérifier : des adresses inexistantes ont répondu "200" par intermittence jusqu’au 7 septembre
Aperçu des brouillons	Le bouton Prévisualiser	Mode brouillon de Next.js, avec un lien signé par WordPress
Cache et purge	Une extension de cache	Cache d’une heure, purge ciblée par webhook à chaque publication
Flux RSS	Natif	Une route codée
Recherche interne	Native	Une route qui interroge l’API, plus sa page de résultats
Pagination des catégories	Native	Une route codée
Formulaire de contact	Gravity Forms, relié à Zapier	Une route codée, un filtre anti-robots (Turnstile), un envoi par Brevo
Inscription à la lettre d’information	Une extension	Une route codée, avec plus de 80 domaines d’e-mails jetables refusés
Commentaires	Natifs	Supprimés, par choix
Adresses du back-office	Rien à faire	Réécriture des liens, fermeture à l’indexation, redirection 301 des pages vers le site public

Le SEO a été la surprise la plus longue. Retravailler les balises Yoast, le plan du site et le reste, ce sont des choses auxquelles je n’étais pas préparé : je l’ai découvert en le faisant. Yoast continue de calculer mes titres dans WordPress, mais c’est le site public qui les écrit dans la page, et chaque oubli se paie en pages mal indexées. Il m’a fallu pas mal itérer pour être 100 % raccord.

L’aperçu des brouillons, ma vraie déception

L’aperçu des brouillons est ce qui m’a le plus coûté. J’ai été un peu déçu, je l’avoue : je me suis rendu compte, à ce moment-là, que se passer d’un WordPress traditionnel est quand même un petit peu différent.

Sur un WordPress classique, le bouton Prévisualiser existe depuis toujours et personne n’y pense. Sur mon site, je l’ai posé le mercredi 25 février, trois jours après la bascule. Le dimanche 1er mars, entre 15 h 23 et 15 h 38, j’ai enchaîné trois correctifs : l’aperçu lancé depuis l’éditeur ne trouvait pas le brouillon, et quitter l’aperçu renvoyait sur une page 404.

Le mercredi 4 mars, c’était pire. Pour savoir quel brouillon afficher, la page lisait un paramètre dans l’adresse, et ce simple paramètre obligeait Next.js à fabriquer toutes les pages à la volée, sans cache : des erreurs 500. Il a fallu passer l’identifiant du brouillon par un cookie. Le 19 mars, j’ai encore dû couper le mode brouillon juste après l’affichage, au lieu de le laisser actif cinq minutes, et en juin, rebelote pour l’aperçu lancé depuis l’éditeur de blocs.

Et le 2 septembre, un audit de sécurité a trouvé plus grave : un visiteur anonyme pouvait lire un de mes brouillons en entier, en tapant simplement l’adresse du site suivie de "/?p=" et de son identifiant. Le site ajoutait lui-même le secret qu’il vérifiait ensuite. Corrigé le jour même : WordPress signe désormais chaque lien d’aperçu, valable deux heures, et sans signature, tout contenu non publié répond 404. Neuf tests automatiques veillent sur cette porte.

Et les commentaires ? Je les ai fermés, par choix. J’estime qu’aujourd’hui on échange avec les gens sur les différents réseaux, et que le commentaire sous un article de blog WordPress n’a plus vraiment d’intérêt. On n’en voit quasiment plus, en 2026.

Combien coûte un WordPress headless chaque mois ?

J’ai fondé et dirigé un hébergeur WordPress, WPServeur, de 2015 à 2020 : je sais lire une facture d’hébergement, et celle-ci m’a surpris. Le site public tourne chez Vercel, sur l’offre Pro à 20 dollars par mois. Sur le papier, un abonnement fixe. Dans les faits :

Période de facturation	Facture Vercel
Premier mois après la bascule	87,36 $
Deuxième mois	66,35 $
23 avril au 22 mai	46,37 $
23 mai au 22 juin	36,75 $
23 juin au 22 juillet	43,64 $
23 juillet au 22 août	52,16 $

Je trouve que les coûts de Vercel ne sont pas fiables. Quand je travaille beaucoup sur le site, la facture grimpe : je passe d’une vingtaine de dollars à plus de 80. Comme je travaille énormément sur WPFormation, ça revient souvent, et je ne l’avais pas anticipé.

La dernière facture le confirme : près des trois quarts (73,7 %) viennent des constructions du site et des écritures du cache, pas du trafic. Autrement dit, ce sont mes chantiers qui font monter la facture, bien plus que mes visiteurs. Chaque correction déclenche une construction complète, chaque publication réécrit des pages en cache, et une soirée de chantier se lit sur la facture du mois.

Côté WordPress, le back-office tourne chez Hetzner, sur un serveur administré par une IA que je partage avec d’autres projets : je ne l’impute pas au site. Le seul coût propre à WPFormation chez Hetzner, pour l’instant, est le petit serveur qui attend de remplacer Vercel, à 6,59 € par mois (5,49 € hors taxes).

Pour mémoire, l’ancien serveur dédié me coûtait 89 € par mois, sans compter l’infogérance.

Reste l’abonnement Claude, l’offre Max à 180 € par mois, qui sert à tous mes projets. Il coûte, mais il m’a aussi fait faire des économies, notamment sur tout mon suivi SEO : il m’évite de payer des outils comme Semrush, et j’en ai fait le calcul dans un article dédié.

Ma note mensuelle, poste par poste :

• Vercel, pour le site public : de 37 à 87 dollars, dont 20 fixes ;
• le serveur Hetzner qui attend de prendre le relais : 6,59 € ;
• WordPress : un serveur partagé avec mes autres projets, non imputé au site ;
• Claude Max : 180 €, pour l’ensemble de mes projets.

Et le temps passé ? Moins d’une heure par semaine pour l’entretien, assisté par l’IA. J’ai un projet qui gère tous mes hébergements web, et tout est automatisé : des e-mails m’indiquent l’état de mes serveurs et les mises à jour en attente, soit avec n8n, soit avec des tâches planifiées.

Ce chiffre d’une heure est vrai, et pourtant trompeur… Depuis le 21 février, le dépôt du site a enregistré plus de 2 000 modifications (des commits), dont plus de 1 100 sur le site public, et Vercel a mis en production plus de 1 100 versions. L’entretien prend une heure ; la construction, elle, n’a jamais vraiment cessé.

Le journal des incidents

Sept mois de production m’ont offert une série d’incidents que mon ancien WordPress n’aurait jamais pu inventer. Je les ai tous datés, historique Git à l’appui.

Date	Ce qui s’est passé	Issue
Lundi 23 février	Pages en 404 après le passage du serveur WordPress en HTTPS, puis tous les articles en noindex, et l’ancien hébergeur en erreur sous les 29 processus parallèles d’une construction	404 réparées à 9 h 30, noindex corrigé à 13 h
1er au 19 mars	L’aperçu des brouillons casse, puis provoque des erreurs 500	Corrigé par étapes, jusqu’au 19 mars
8 et 19 mars	Des adresses inexistantes redeviennent de fausses pages, servies avec un code 200	Corrigé pour de bon le 7 septembre
24 au 27 avril	Plan du site, robots.txt et llms.txt coupés par une correction	56 heures
30 avril	Le module de paiement Stripe ne se connecte plus une fois déployé sur Vercel	Corrigé le 30 avril
28 mai	Le pare-feu de l’ancien hébergeur bannit l’adresse IP de mon bureau	WordPress déménagé chez Hetzner le dimanche 31 mai, vers 6 h 30
23 au 25 août	Carte refusée, trois courriels "Payment Failed And Shutdown Coming Soon"	Facture réglée le 25, sans interruption de service
2 septembre	Un audit découvre que les brouillons sont lisibles par un visiteur anonyme	Corrigé le jour même, lien d’aperçu signé
4 septembre	Construction réussie, déploiement en échec après une montée de version de Next.js	Corrigé dans la matinée
5 septembre	Le projet Vercel tournait en Node 24, tout le reste en Node 22, sans que personne l’ait choisi	Réaligné le jour même
22 septembre	Faille critique publiée dans Next.js, sur la génération des images de partage	Corrigée en production le 24

Le pire : 56 heures sans plan du site

Le pire reste le souvenir du 24 au 27 avril. Ce vendredi-là, à 21 h 33, je mets en ligne une correction que je pensais sûre et fiable : renvoyer une vraie erreur 404 aux robots qui sondent le site à la recherche de fichiers sensibles. La règle attrapait tout ce qui ressemblait à un nom de fichier… y compris mon sitemap.xml, mon robots.txt et mon llms.txt.

Le week-end passe. Rien ne casse à l’écran, les pages s’affichent, les visiteurs lisent. C’est Search Console qui donne l’alerte : impossible de lire le sitemap, erreur HTTP 404. La réparation part le lundi 27, à 5 h 43. Cinquante-six heures pendant lesquelles Google n’a plus pu lire mon plan du site, ni les assistants IA mon fichier llms.txt.

Huit minutes après la réparation, un contrôle automatique voyait le jour. Chaque matin à 8 h 15, il vérifie aujourd’hui dix-huit adresses essentielles et m’écrit dès que l’une d’elles casse.

Moins d’extensions, pas moins de mises à jour

Côté sécurité, je trouve le headless beaucoup plus sûr : très difficile de pirater un WordPress headless. Bien sûr, il reste le vecteur d’attaque du back-office, mais pour tout le reste, c’est plutôt pas mal, puisque je n’ai quasiment plus aucun plugin. Tout le reste est développé.

Les chiffres vont dans ce sens. L’ancien site faisait tourner 37 extensions ; le back-office actuel en garde quatre, dont Yoast. Son adresse ne sert à personne d’autre que moi : pages redirigées vers le site public, fermeture à l’indexation, page de connexion déplacée, accès XML-RPC bloqué.

Mais le code n’a pas disparu, il a changé de mains. Là où j’avais des extensions à mettre à jour, j’ai aujourd’hui 26 fichiers de code maison côté WordPress (des mu-plugins) et un site Next.js entier, que personne d’autre que moi ne relit. La faille des brouillons du 2 septembre vient de ce code-là, pas d’une extension.

Et le site public a ses propres failles, qui ne préviennent pas. Depuis juillet, j’ai monté Next.js de version cinq fois, dont au moins trois pour corriger des failles de sécurité. La dernière était critique : publiée le 22 septembre, corrigée en production le 24. Avoir moins d’extensions ne m’a pas dispensé de mises à jour : elles portent simplement sur Next.js au lieu des plugins.

Quelle part du code Claude Code a-t-il écrite ?

Presque tout. Depuis le 21 février, 1 875 des 2 086 commits du dépôt (hors fusions) portent la co-signature de Claude, soit neuf sur dix, dès le tout premier, le samedi 21 février à 0 h 27. En mars, il les a tous co-signés.

Sa part : toute la partie code, et la mise en place des différentes briques d’hébergement, chez Vercel comme chez Hetzner. La mienne : décider, relire, tester et faire corriger. Je détaille cette méthode dans ma façon d’utiliser Claude Code sur plus de 300 articles, et je l’ai poussée plus loin en laissant une IA gérer mon WordPress pendant 30 jours.

Il m’a surtout sauvé la mise sur les hébergements. Je ne connaissais absolument pas Vercel. Il existe un serveur MCP pour Vercel (un connecteur qui permet à l’IA de piloter le service) qui fonctionne très bien : Claude s’en est servi pour régler et dépanner, et j’ai gagné un temps fou.

Là où j’ai dû le rattraper : le week-end d’avril, quand il a exclu mon sitemap et mon robots.txt, et ces erreurs où il prenait des 404 pour des 200. Les commits fautifs portent sa signature, comme les réparations. La responsabilité reste la mienne : c’est moi qui décide de ce qui part en ligne.

Sans l’IA, clairement, je ne me serais pas lancé. Maîtriser Claude Code m’a permis de gagner énormément de temps et d’éviter de nombreux écueils… pas tous, vous l’avez compris.

Vercel : pourquoi je vais tout rapatrier chez Hetzner

Je préfère tout passer chez Hetzner. J’y aurai une visibilité concrète et réelle sur les coûts de mon hébergement, plutôt qu’un abonnement soi-disant fixe qui, au final, se paie à l’usage. C’est le plus adapté pour moi, qui travaille énormément sur WPFormation.

La sortie est prête depuis le 10 août : le serveur qui prendra le relais tourne déjà, en Finlande. Je n’ai pas encore fixé la date. Fin août, j’ai choisi de mesurer d’abord ce que coûtent les écritures du cache, pour savoir quelle part de la facture vient de Vercel et quelle part vient de ma configuration.

Deux épisodes ont pesé dans la balance. En août, ma carte a été refusée trois jours de suite, avec à chaque fois un courriel intitulé "Payment Failed And Shutdown Coming Soon" : la production d’un site professionnel suspendue à un prélèvement.

Et en septembre, j’ai découvert que le projet tournait en Node 24, quand tout le reste était réglé sur Node 22. Rien de grave, mais je ne veux plus découvrir mon hébergement par surprise.

Les pièges à connaître avant de passer en headless

Si c’était à refaire, je lirais davantage de retours d’expérience de gens qui l’ont déjà fait, pour gagner du temps sur tous les petits pièges que j’ai découverts un par un. Les miens, tels que je les ai vécus, avec ce que je ferais dès le premier jour :

1. Faire l’inventaire des extensions avant de toucher au code. Chacune rend un service que le nouveau site devra rendre à sa place : balises SEO, formulaires, redirections, cache, aperçu. Listez-les toutes, et chiffrez le temps de chacune.
2. Vérifier ce que le back-office dit aux robots. Mon back-office est volontairement réglé pour décourager les moteurs de recherche (personne ne doit l’indexer), et le site public a fidèlement recopié ce réglage : tous mes articles en noindex, un lundi matin. Contrôlez la balise robots de trois pages avant de basculer l’adresse.
3. Tester une adresse qui n’existe pas. Elle doit répondre 404, pas 200 avec une page vide. Chez moi, ces fausses pages sont revenues par intermittence pendant six mois, au gré de modifications sans rapport.
4. Protéger les fichiers que lisent les robots. Plan du site, robots.txt, llms.txt, flux RSS : une règle de sécurité trop large les a coupés pendant 56 heures. Une liste blanche et un contrôle quotidien automatique, dès le premier jour.
5. Construire l’aperçu des brouillons en premier, et le signer. C’est la fonction que vos rédacteurs utilisent le plus, et la plus facile à rater, jusqu’à laisser lire un brouillon par n’importe qui.
6. Surveiller la facture dès le premier mois. Chez un hébergeur facturé à l’usage, chaque construction du site et chaque écriture du cache se paient. Regardez le détail de la première facture, et posez un plafond de dépenses.
7. Épingler les versions. Node, Next.js, les bibliothèques : si vous ne fixez rien, l’hébergeur ou une mise à jour choisira pour vous.
8. Brancher Context7 avant la première ligne de code. Ce connecteur donne à l’IA la documentation à jour de Next.js et des autres bibliothèques. Pour moi, c’est une obligation : sans elle, l’IA code avec la documentation de sa date d’entraînement.

Je ne dresse pas un tableau noir pour autant. Aujourd’hui, j’ai appris à travailler avec mon WordPress headless, et c’est un vrai bonheur d’utiliser cette technologie quand on la maîtrise, et quand on est assisté par un outil tel que Claude Code.

Est-ce que je le referais, et pour qui ?

Oui, bien sûr. Je suis d’ailleurs déjà en train de le refaire pour AKMENS, un WordPress headless qui proposera de la formation professionnelle aux entreprises, pour former rapidement et efficacement leurs équipes sur le marketing, l’IA ou le bien-être au travail.

Ce que j’apprécie tout particulièrement, c’est de m’affranchir totalement des limites des thèmes. Je n’ai plus aucune limite dans mes choix de design, et les neuf outils gratuits du site comme son serveur MCP public sont nés de cette liberté.

Je le déconseille à ceux qui ne maîtrisent pas aujourd’hui assez bien WordPress et l’IA. Un site headless ne s’installe pas comme un thème : il faut le construire, puis l’entretenir, et sans l’IA le temps nécessaire serait bien plus important.

Pour trancher sur votre propre site, je vous invite à commencer par mon guide complet du WordPress headless, avantages et pièges compris. Sept mois plus tard, je referais la bascule sans hésiter, en me fiant cette fois aux mesures de mes visiteurs plutôt qu’au laboratoire.

Questions fréquentes

Combien coûte un WordPress headless par mois ?

Dans mon cas, entre 37 et 87 dollars par mois pour le site public chez Vercel, selon le volume de travail, plus le serveur qui héberge WordPress. Le plan gratuit de Vercel est réservé aux projets personnels non commerciaux. Chez Hetzner, un petit serveur démarre à 5,49 € hors taxes par mois.

Un WordPress headless est-il plus rapide pour les visiteurs ?

Je le pense, et je le vis au quotidien, mais je ne peux pas le prouver : la seule mesure de terrain de mon ancien site, relevée en février, était même meilleure sur ordinateur (1,0 seconde pour afficher le contenu principal). Aujourd’hui, sur wpformation.com, les données de terrain de Chrome donnent un affichage du contenu principal en 1,8 seconde sur mobile et 1,35 seconde sur ordinateur, sous le seuil de 2,5 secondes fixé par Google, avec une première réponse du serveur à 450 ms sur mobile.

Quelles fonctions WordPress faut-il refaire en headless ?

Tout ce que WordPress et ses extensions affichaient d’eux-mêmes : balises SEO de Yoast, plan du site, robots.txt, redirections, vraies pages 404, aperçu des brouillons, purge du cache, flux RSS, recherche interne, pagination, formulaires et commentaires. Sur mon site, la plus coûteuse a été l’aperçu des brouillons.

Faut-il savoir coder pour passer en headless ?

Il faut au minimum maîtriser WordPress et savoir piloter une IA de développement. Sur mon site, Claude Code a co-signé neuf modifications sur dix, mais les décisions, la relecture et les tests restent les miens, et les incidents se jouent précisément là.

Le passage en headless fait-il perdre du trafic Google ?

Pas dans mon cas. De mars à mai, mes clics Google ont progressé de 11 % par rapport aux mêmes jours de 2025, en conservant les adresses, les métadonnées, le plan du site et les redirections. Le recul de septembre coïncide avec l’arrivée des aperçus IA de Google en France, fin juillet.

Un site headless est-il mieux cité dans les aperçus IA de Google ?

Rien ne le prouve. Google cite des pages qui répondent à la question, quelle que soit la technique qui les affiche : deux des quatre pages de mon site les plus montrées par son IA datent de 2016. Le headless facilite surtout les portes dédiées aux assistants (llms.txt, versions Markdown, serveur MCP), dont l’effet reste à mesurer.

Article original sur WPFormation