Un client m'a appelé en 2021, une marque e-commerce de taille moyenne à Manchester, avec environ 40 000 SKU, plusieurs vitrines régionales, furieux. Ils avaient dépensé 180 000 £ sur 18 mois pour un build Shopify headless avec un front-end Next.js, et leurs temps de chargement des pages étaient plus lents que le thème Shopify qu'ils avaient remplacé. Leur équipe de développement était passée d'un contractant à quatre. Les éditeurs de contenu avaient besoin d'un développeur sur place juste pour publier un article de blog.Next.js front end, and their page load times were 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.
Point clé : Optez pour une architecture headless si vous avez réellement besoin de plusieurs interfaces ou de performances qu'un monolithe ne peut pas atteindre ; un seul site WordPress avec un bon thème vaut mieux que trois développeurs qui maintiennent une stack dont vous n'aviez pas besoin.Go headless when you genuinely need multiple front ends or performance a monolith cannot hit; one WordPress site with a good theme beats three developers maintaining a stack you did not need.
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é plus de 12 000 sites chez Seahawk Media. Headless a été le bon choix sur peut-être 8-10 % d'entre eux. Les 90 % restants ? Ça aurait été un désastre, coûteux, lent à livrer, et pénible à maintenir. Cet article parle de savoir dans quel camp votre projet se situe avant d'avoir déjà signé les chèques.
---
Ce que « sans tête » signifie vraiment en pratique
Défaisons-nous rapidement de la définition. Un CMS traditionnel, WordPress, Squarespace, peu importe, couple le back-end de gestion de contenu à la couche de présentation front-end. Ils communiquent entre eux nativement. 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, ce que vous voulez, récupère ce contenu et le rend comme il l'entend.WordPress, Squarespace, whatever, couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end, Next.js, Nuxt, Astro, SvelteKit, whatever you fancy, fetches that content and renders it however it wants.
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à la chose, il y a de vraies raisons légitimes de faire ça. Je ne rejette pas l'architecture. Je suis juste fatigué de voir l'appliquer 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 app mobile, un écran de borne, et une interface de smart TV, un CMS couplé devient véritablement pénible. Une seule API de contenu que quatre surfaces interrogent ? Ça a vraiment du sens. Seahawk avait un client dans l'hôtellerie à Dubaï, un de ces groupes de resorts avec un site public, une app interne pour le personnel, et de la signalétique numérique dans tout l'établissement. Une seule instance Sanity alimentant tout. 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 à vrai dire échelle est le deuxième argument légitime. Les pages générées statiquement servies depuis un edge CDN sont rapides d'une façon que les pages WordPress rendues en PHP ne peuvent simplement pas être, peu importe comment vous avez optimisé votre serveur. Quand on parle de millions de pages vues par mois, ces millisecondes s'accumulent en différences de revenus significatives. Les recherches de Google ont documenté la corrélation entre la vitesse de chargement et le taux de conversion à plusieurs reprises, 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 juste de découvrir Next.js et veulent l'utiliser partout. (J'étais coupable de ça moi-même en 2019, j'ai construit un blog headless pour un petit client association, j'ai passé trois jours à configurer des webhooks pour déclencher des rebuilds Netlify sur de nouveaux posts, je les ai facturisés, et ils m'appellent encore quand quelque chose casse.) Le problème c'est que headless déplace la complexité opérationnelle du CMS à l'infrastructure. WordPress se met à jour tout seul. Votre pipeline Next.js + Contentful personnalisé ne le fait pas.
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'UX éditorial d'un vrai CMS couplé comme WordPress est véritablement meilleur qu'un CMS headless. Les environnements de preview sont plus difficiles. L'édition inline a disparu. Le WYSIWYG est neutralisé., 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, un vrai build headless coûte 2 à 3 fois plus qu'un build WordPress comparable en développement, 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.
- Des changements de contenu fréquents, la génération statique signifie des temps de build. 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émentale 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 config 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 back-end headless, en utilisant WP REST API ou WPGraphQL, vous offre l'expérience de gestion de contenu que vos clients connaissent déjà (et honnêtement, la plupart des clients connaissent WordPress), combinée avec la flexibilité d'un front-end moderne. Vous ne payez pas pour Contentful. Vous ne recyclez 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 bien particulièrement pour les sites marketing qui ont une importante bibliothèque de contenu existante dans WordPress et ne veulent pas migrer, mais veulent un front-end React pour des raisons de performance ou d'interactivité. Le compromis est que la maintenance du plugin WPGraphQL peut devenir délicate, et vous tournez toujours un serveur PHP, vous n'avez pas complètement échappé à 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. API solide, bons SDKs, UI éditoriale raisonnable. La tarification est le point faible, le tier gratuit est vraiment utile pour les petits projets, mais une fois que vous atteignez les limites, vous regardez 300+$/mois avant d'avoir fait quoi que ce soit d'intéressant. Je choisirais Contentful pour les projets avec de vrais budgets et les organisations qui ont besoin de workflows appropriés de rôles et permissions.
Sanity
Mon préféré personnel pour la plupart des projets headless du mid-market. Le langage de requête GROQ est expressif une fois que vous y avez passé une journée, Sanity Studio est customisable d'une manière que Contentful ne l'est pas, et la collaboration en temps réel est excellente. La tarification est plus raisonnable. L'inconvénient est que la courbe d'apprentissage pour les éditeurs de contenu non-techniques est plus raide, le Studio ressemble assez différent 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 avec beaucoup de contenu qui sont surtout statiques, documentation, blogs, sites marketing, Astro avec des collections de contenu locales mérite d'être considéré. Aucun CMS du tout. Le contenu vit comme fichiers Markdown ou MDX dans le repo. Les développeurs adorent. Les éditeurs non-techniques le détestent généralement. Connaissez votre audience avant de prendre cette direction.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 entreprise SaaS, environ 80 pages, trafic modéré, passée d'une installation WordPress gérée à Next.js avec Sanity, déployée sur Vercel. Avant la migration, les scores Lighthouse s'affichaient autour de 62-68 sur mobile. Après, constamment 91-96. Le Time to First Byte a chuté de roughly 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 de contenu de quatre personnes qui ont suivi la formation Sanity, et un budget qui a absorbé une construction de huit semaines. Les gains de performance étaient réels parce que les conditions pour faire fonctionner le 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 ?
Dépend entièrement de ce que « mieux » signifie pour votre projet spécifique. Pour la livraison multi-canal, la séparation des équipes, ou la performance à haut volume de trafic, le WordPress headless, ou remplacer WordPress par un CMS headless dédié, peut améliorer les choses de manière significative. Pour un site web d'entreprise standard avec une petite équipe et un trafic modéré, WordPress traditionnel avec un bon thème et un bon caching est plus facile à construire, moins cher à gérer, 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 combiné avec Astro ou Next.js déployé sur le tier gratuit de Vercel peut vous donner une architecture headless fonctionnelle pour très peu de coûts mensuels. Vous paierez en temps de développeur à la place. Rien n'est vraiment gratuit, vous choisissez juste où le coût se situe.
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 dans une architecture headless que dans 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. Tenez-en compte honnêtement dans les délais et les devis — les clients à qui on a dit « juste quelques semaines » pour un build headless, quand cela finit par prendre 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 à la base. Gutenberg a grignoti certains scénarios où le headless était autrefois justifié, les expériences de contenu interactives et orientées composants sont maintenant plus réalisables dans WordPress sans découplage. À la haute extrémité, pour la publication multi-canal et le commerce à grande échelle, le 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. Connaissez 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. Ils ont réduit leurs frais généraux de développement de 60 % et leurs temps de chargement se sont enfin améliorés. Parfois, l'ancienne méthode est la bonne. Il n'y a pas de honte à cela.