Un client m'a appelé en 2021 — une marque e-commerce de taille moyenne basée à Manchester, environ 40 000 SKU, plusieurs vitrines régionales — furieux. Ils avaient dépensé 180 000 £ sur 18 mois pour une architecture sans tête Shopify avec un front-end Next.js, et les temps de chargement de leurs pages étaient plus lents que le thème Shopify qu'ils avaient remplacé. Leur équipe de développement était passée d'un prestataire à quatre personnes. Les éditeurs de contenu avaient besoin d'un développeur présent juste pour mettre en ligne un article de blog.slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
L'architecture sans tête leur avait été vendue comme l'avenir. Et techniquement, c'est le cas. Mais personne ne leur avait dit ce que cela coûterait réellement à exploiter.
J'ai construit ou supervisé la construction de plus de 12 000 sites chez Seahawk Media. L'architecture sans tête a été le bon choix pour environ 8 à 10 % d'entre eux. Les 90 % restants ? Cela aurait été un désastre — coûteux, lent à mettre en production, et pénible à maintenir. Cet article porte sur la façon de savoir dans quel cas votre projet se situe avant d'avoir déjà signé les chèques.
---
Ce que « sans tête » signifie vraiment en pratique
Commençons par définir rapidement le concept. Un CMS traditionnel — WordPress, Squarespace, peu importe — couple le back-end de gestion de contenu à la couche de présentation front-end. Ils communiquent naturellement entre eux. Le headless les découple. Votre CMS (Contentful, Sanity, Strapi, WordPress en mode headless) devient une pure API de contenu. Votre front-end — Next.js, Nuxt, Astro, SvelteKit, ou ce que vous préférez — récupère ce contenu et l'affiche comme bon lui semble.
Idée simple. La complexité s'insinue partout ailleurs.
Le stack qui apparaît réellement sur les projets
En pratique, quand quelqu'un dit « headless », il parle généralement d'une de ces combinaisons :
- Contentful ou Sanity comme CMS, servant du JSON via REST ou GraphQL as the CMS, serving JSON over REST or GraphQL
- Next.js en front-end, soit généré statiquement (SSG), soit rendu côté serveur (SSR) on the front end, either statically generated (SSG) or server-side rendered (SSR)
- Vercel ou Netlify pour le déploiement et les edge functions for deployment and edge functions
- Shopify Storefront API ou BigCommerce s'il y a du commerce impliqué or BigCommerce if there's commerce involved
- Une version ou l'autre d'Algolia pour la recherche, parce que les options de recherche natives sont généralement nullesAlgolia for search, because the native search options are usually rubbish
Chacun de ceux-ci est une relation commerciale distincte, une ligne de facturation séparée, et quelque chose qui peut mal tourner à 2h du matin un vendredi.
---
Le vrai cas pour passer en headless
Voilà le truc — il y a de vraies raisons légitimes de le faire. Je ne rejette pas l'architecture. Je suis juste fatigué de la voir appliquée sans discernement.
La livraison de contenu multi-canal est l'argument le plus solide. Si le même contenu doit apparaître sur un site web, une application mobile, un écran de kiosque et une interface de smart TV, un CMS couplé devient genuinely pénible. Une seule API de contenu que les quatre surfaces interrogent ? Ça a vraiment du sens. Seahawk avait un client de l'hôtellerie à Dubaï — l'un de ces groupes de stations balnéaires avec un site grand public, une application interne pour le personnel et de la signalisation numérique partout. Une seule instance Sanity qui alimente tout ça. C'était le bon choix, point final. is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai — one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
La performance à grande échelle est le deuxième argument légitime. Les pages générées statiquement servies depuis un edge CDN sont rapides d'une manière que les pages WordPress rendues en PHP ne sont simplement pas, peu importe la qualité de votre optimisation serveur. Quand on parle de millions de pages vues par mois, ces millisecondes s'accumulent en différences de revenus significatives. La recherche de Google a documenté à plusieurs reprises la corrélation entre la vitesse de chargement et le taux de conversion — ce n'est pas théorique. is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly — it's not theoretical.
La séparation des équipes compte aussi, mais seulement pour les organisations assez grandes pour avoir des équipes front-end et back-end distinctes. Si votre équipe de contenu est un département marketing de 20 personnes qui veut avancer indépendamment de votre équipe d'ingénierie, un contrat d'API propre entre le CMS et le front-end permet aux deux côtés de travailler sans se bloquer mutuellement. matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
Ces trois cas ? Ils valent vraiment le coût de la complexité. Tout le reste est généralement du vœu pieux déguisé en architecture.
---
Quand le headless est juste une sur-ingénierie coûteuse
Un site brochure de cinq pages pour un cabinet comptable londonien n'a pas besoin d'une architecture headless. Pas plus qu'une boutique WooCommerce avec 200 produits et un développeur sur appel.
Je vois cette erreur constamment, surtout chez les développeurs qui viennent de découvrir Next.js et veulent l'utiliser partout. (J'en suis moi-même coupable en 2019 — j'ai construit un blog headless pour un petit client associatif, j'ai passé trois jours à configurer des webhooks pour déclencher les reconstructions Netlify sur de nouveaux articles, je leur ai facturé, et ils m'appellent toujours quand quelque chose casse.) Le problème, c'est que le headless déplace la complexité opérationnelle du CMS vers l'infrastructure. WordPress se met à jour tout seul. Votre pipeline Next.js + Contentful personnalisé, non.
Scénarios spécifiques où le headless coûte généralement plus qu'il ne rapporte :
- Petites équipes de contenu — si une ou deux personnes gèrent tout le contenu, l'expérience éditoriale d'un vrai CMS couplé comme WordPress est véritablement meilleure qu'un CMS headless. Les environnements de prévisualisation sont plus difficiles. L'édition intégrée disparaît. WYSIWYG est affaibli. — if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- Budgets serrés — une véritable construction headless coûte 2 à 3 fois plus cher qu'une construction WordPress comparable à développer, et la maintenance continue est plus élevée. Si le budget est une contrainte, cet argent fait presque toujours plus de bien ailleurs. — a proper headless build costs 2–3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- Changements de contenu fréquents — la génération statique signifie des temps de compilation. Un éditeur de news qui pousse 50 articles par jour n'a pas envie d'attendre 8 minutes pour une reconstruction complète du site à chaque fois. (Oui, la régénération statique incrémentielle aide. Elle ajoute aussi sa propre complexité.) — static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- Pas de DevOps dédié — quelqu'un doit être responsable du pipeline de déploiement, de la configuration CDN, des variables d'environnement, des URLs de prévisualisation. Dans une petite équipe, ce quelqu'un est généralement le développeur qui fait aussi tout le reste. — someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
Le Juste Milieu WordPress Headless
Ce sur quoi j'aimerais revenir, c'est le faux choix entre « WordPress traditionnel » et « headless complet avec un CMS séparé ». Il existe un chemin intermédiaire qui fonctionne vraiment bien pour une certaine classe de projet.
WordPress comme backend headless — en utilisant WP REST API ou WPGraphQL — vous donne l'expérience de gestion de contenu que vos clients connaissent déjà (et honnêtement, la plupart des clients connaissent WordPress), combinée à la flexibilité d'un front end moderne. Vous ne payez pas Contentful. Vous ne reconvertissez personne. L'équipe éditoriale garde Gutenberg. Le front end peut être n'importe quel framework qui convient au projet.WP REST API or WPGraphQL — gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
J'ai utilisé ce pattern sur probablement 30–40 projets au cours des quatre dernières années. Ça fonctionne particulièrement bien pour les sites marketing qui ont une importante bibliothèque de contenu existante dans WordPress et ne veulent pas migrer, mais qui veulent un front-end React pour des raisons de performance ou d'interactivité. Le compromis, c'est que la maintenance du plugin WPGraphQL peut devenir fastidieuse, et vous continuez à faire tourner un serveur PHP — vous ne vous êtes pas complètement échappé de l'hébergement WordPress.
---
Choisir votre headless CMS : Une comparaison pratique
Tous les headless CMSes ne sont pas identiques, et le choix compte plus que les gens ne l'admettent quand ils s'enthousiasment pour leur framework front-end.
Contentful
L'option de niveau entreprise. Une API solide, de bons SDKs, une UI éditoriale raisonnable. Le prix est le point sensible — le plan gratuit est vraiment utile pour les petits projets, mais une fois que vous dépassez les limites, vous regardez 300 $/mois minimum avant d'avoir fait quoi que ce soit d'intéressant. Je choisirais Contentful sur les projets avec de vrais budgets et les organisations qui ont besoin de workflows appropriés de rôles et de permissions.
Sanity
Mon préféré personnel pour la plupart des projets headless mid-market. Le langage de requête GROQ est expressif une fois que vous y avez passé un jour, Sanity Studio est customisable d'une manière que Contentful ne l'est pas, et la collaboration en temps réel est excellente. Le prix est plus raisonnable. L'inconvénient, c'est que la courbe d'apprentissage pour les éditeurs de contenu non-techniques est plus raide — le Studio a une apparence assez différente de WordPress pour qu'il y ait toujours une période de formation.GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper — the Studio looks different enough from WordPress that there's always a training period.
Strapi
Open-source, auto-hébergé, gratuit à faire tourner. Si vous avez un client qui ne paiera pas de frais SaaS pour un CMS et qui a un serveur, Strapi vaut la peine d'être considéré. Le panneau d'administration est correct. Mais vous prenez à votre charge l'hébergement, les mises à jour et les correctifs de sécurité. Ce n'est pas rien.
Astro avec content collections
Pour les sites à fort contenu qui sont principalement statiques — documentation, blogs, sites marketing — Astro avec des content collections locales mérite considération. Aucun CMS du tout. Le contenu vit sous forme de fichiers Markdown ou MDX dans le repo. Les développeurs adorent ça. Les éditeurs non-techniques généralement la détestent. Connaissez votre audience avant de suivre cette voie.Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
L'Argument Performance : Ce que les Chiffres Disent Réellement
Laissez-moi vous donner un vrai benchmark plutôt qu'une affirmation vague sur la vitesse.
Un client Seahawk — une compagnie SaaS, environ 80 pages, trafic modéré — est passée d'une installation WordPress managée à Next.js avec Sanity, déployée sur Vercel. Avant la migration, les scores Lighthouse tournaient autour de 62–68 sur mobile. Après, régulièrement 91–96. Le Time to First Byte est tombé d'environ 420ms à moins de 80ms. Ce n'est pas une amélioration marginale. C'est un produit différent.
Mais — et c'est important — ils avaient un développeur front-end dédié, une équipe contenu de quatre personnes qui ont suivi une formation Sanity, et un budget qui a absorbé huit semaines de build. Les gains performance étaient réels parce que les conditions pour faire fonctionner headless étaient en place.
Les données du Web Almanac sur la performance des CMS montrent que l'écart performance entre les frameworks orientés headless et les CMS couplés traditionnels est réel mais pas automatique. Un site Next.js mal implémenté peut absolument sous-performer un site WordPress bien configuré. L'architecture seule ne vous sauve pas.Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
Prendre la Décision : Un Framework que J'Utilise Réellement
Quand un brief client atterrit sur mon bureau et qu'il y a un doute sur la pertinence d'une architecture headless, je me pose cinq questions avant de m'engager sur une recommandation.
- Le contenu doit-il apparaître sur plus d'une surface ? Si oui, headless mérite un examen sérieux. Si non, on perd une justification majeure. If yes, headless gets a serious look. If no, it loses a major justification.
- Quel est le niveau de confort technique de l'équipe éditoriale ? Des éditeurs non-techniques sous une deadline serrée dans un CMS peu familier, c'est une mauvaise combinaison. Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- Quel est le trafic attendu et les exigences de performance ? Moins de 50 000 visiteurs mensuels sur un hébergement correct ? WordPress le gère sans problème. Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- Y a-t-il un développeur dédié pour la maintenance continue ? Si la réponse est « on appellera quelqu'un quand ça cassera », l'infrastructure headless devient un problème. If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- Quel est le budget réel, y compris la première année d'exploitation ? Pas juste la construction. L'hébergement, les abonnements CMS, le temps développeur pour les mises à jour. Le coût total de possession. Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
Si les questions 1, 4 et 5 ne s'alignent pas, je recommande une approche traditionnelle ou hybride et je dors tranquille.
---
FAQ
Headless WordPress est-il mieux qu'une configuration WordPress traditionnelle ?
Cela dépend entièrement de ce que signifie « mieux » pour votre projet spécifique. Pour une livraison multi-canal, une séparation des équipes, ou des performances à fort trafic, un WordPress headless — ou remplacer WordPress par un CMS headless dédié — peut améliorer significativement les choses. Pour un site web standard d'entreprise avec une petite équipe et un trafic modéré, WordPress traditionnel avec un bon thème et un cache approprié est plus facile à construire, moins cher à exploiter, et plus simple à transférer à un client.
Headless signifie-t-il toujours de meilleures performances ?
Non. Et ce mythe cause de vrais dégâts aux budgets de projet. Les pages générées statiquement et servies depuis un CDN sont plus rapides par défaut, mais une construction headless mal configurée avec des images non optimisées, des requêtes API en cascade, et pas de cache approprié peut absolument sous-performer un site WordPress bien réglé. Les performances, c'est une question d'exécution, pas juste d'architecture.by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
Quel est le moyen le moins cher de passer à headless ?
Strapi sur un VPS à 5 £/mois associé à Astro ou Next.js déployé sur le tier gratuit de Vercel peut vous donner une configuration headless fonctionnelle pour très peu par mois. Vous paierez en temps développeur à la place. Rien n'est vraiment gratuit — vous choisissez juste où le coût retombe.
Combien de temps prend généralement une construction headless comparée à une construction CMS traditionnel ?
D'après mon expérience : un projet comparable prend environ 1,5 à 2,5 fois plus longtemps en configuration headless qu'en WordPress, surtout si c'est le premier projet headless de l'équipe. Cet écart se réduit au fur et à mesure que l'équipe se familiarise avec la stack. Intégrez cela honnêtement dans les délais et devis — les clients à qui on a dit « juste quelques semaines » pour une construction headless, qui finissent par en attendre quatre mois, ne reviennent pas.
Headless est-il en train de mourir maintenant que WordPress a l'Éditeur de Blocs ?
Non, mais les cas d'usage se rétrécissent à l'extrémité basse. Gutenberg a grignoté certains scénarios où headless était autrefois justifié — les expériences de contenu interactives et pilotées par composants sont plus accessibles dans WordPress maintenant sans découplage. Au haut de gamme, pour la publication et le commerce multi-canal à grande échelle, headless est aussi pertinent qu'il ne l'a jamais été.
---
Le headless n'est pas un symbole de statut. C'est un compromis — plus de flexibilité, plus de complexité, plus de coûts, en échange de véritables gains dans des situations spécifiques. Connaître la situation avant de vous engager. Le client e-commerce de Manchester que j'ai mentionné au début a finalement migré vers un thème Shopify avec quelques composants front-end personnalisés. Il a réduit ses frais de développement de 60 % et ses temps de chargement se sont enfin améliorés. Parfois, l'ancienne façon est la bonne. Il n'y a pas de honte à cela.