Pourquoi cette question se pose
Dans beaucoup de projets, la question du headless WordPress n’arrive pas au début. Elle apparaît plus tard, au moment où le site doit faire plus que publier des pages : alimenter une application mobile, servir plusieurs canaux, s’intégrer au système d’information, tenir une promesse de performance, ou absorber une refonte devenue sensible entre IT, produit et marketing.
Côté IT, le sujet remonte souvent après une mauvaise expérience WordPress, avec en toile de fond la crainte de la dette technique, des mises à jour mal maîtrisées ou d’un CMS perçu comme insuffisamment robuste pour un contexte exigeant. Côté direction produit ou digitale, la douleur est souvent plus concrète : budgets qui dérivent, arbitrages mal posés, promesses de stack “future-proof” qui ne disent pas clairement ce qu’elles coûtent ensuite au quotidien. Côté marketing, le paradoxe est bien connu : on demande une stack plus moderne, puis l’on découvre que la prévisualisation, l’autonomie éditoriale et la vitesse de publication se sont dégradées.
C’est précisément pour cela que le sujet se complique. Le terme headless mélange souvent plusieurs réalités : un vrai besoin produit, une contrainte SI légitime, ou simplement un effet de mode bien présenté.
L’enjeu n’est donc pas de savoir si le headless est moderne. L’enjeu est de déterminer s’il crée, dans votre contexte, plus de valeur que de complexité. C’est ce cadre de décision que cet article propose de poser, avant d’entrer dans les cas où l’architecture devient réellement utile.
L’essentiel en 30 secondes
Le headless WordPress n’est pas une version “premium” de WordPress. C’est un choix d’architecture qui sépare le back-office du front, avec un intérêt réel dans certains contextes bien identifiés : multi-canal, mobile ou offline, content hub connecté au SI, ou produit média très cadré.
Pour un site web classique, ce choix ajoute souvent surtout de la complexité : deux stacks, deux pipelines, deux zones d’incident, une prévisualisation plus coûteuse, et une autonomie éditoriale qui peut reculer si elle n’est pas pensée dès le départ.
En pratique, la recommandation la plus solide n’est pas “tout headless”. C’est souvent une approche hybride : WordPress et Gutenberg pour le web, headless pour les usages hors web qui le justifient vraiment. La bonne question n’est donc pas “est-ce moderne ?”, mais “est-ce justifié par votre produit, votre organisation et votre capacité de run ?”.
Headless WordPress, en clair : ce que vous découpez, ce que vous gagnez, ce que vous perdez
Définition simple : WordPress garde le contenu, le front part ailleurs
Dans une architecture headless, WordPress ne joue plus le rôle complet de CMS et de moteur de rendu. Il conserve le back-office, le modèle de contenu, les workflows éditoriaux, parfois une partie des rôles et permissions, puis expose les données via la REST API ou WPGraphQL. L’interface vue par l’utilisateur est, elle, rendue par un front séparé, souvent en Next.js, Nuxt ou dans un framework équivalent.
Autrement dit, vous ne remplacez pas simplement un thème. Vous découpez la chaîne de valeur du site.
Ce découpage peut être très pertinent lorsqu’un même contenu doit alimenter plusieurs interfaces. Mais il peut aussi créer un faux sentiment de modernité : on pense acheter un meilleur WordPress, alors qu’on introduit en réalité une seconde plateforme à concevoir, tester, déployer et maintenir.
Pour prendre la bonne décision, il faut donc regarder la profondeur du découplage, pas seulement son étiquette.
Headless pur et headless hybride : une nuance qui change tout
Le headless pur est l’option la plus radicale. WordPress ne rend plus vraiment le site web. Il devient essentiellement une source de contenu et, parfois, un poste d’administration.
Le headless hybride est souvent plus intéressant dans les projets structurés. Le site web reste rendu par WordPress sur tout ou partie du périmètre, tandis que certains contenus ou services sont exposés via API pour d’autres canaux : application mobile, espace connecté, borne, portail métier, moteur de recherche interne ou écran embarqué.
Sur le terrain, cette nuance change beaucoup de choses. Le headless pur crée une rupture plus forte sur les workflows, la preview, la gestion des blocs, le SEO technique et les responsabilités d’exploitation. L’hybride permet au contraire de cibler précisément la zone où la découpe crée de la valeur, sans payer le coût maximum partout. Et c’est ce qui explique pourquoi, dans beaucoup de cas, la discussion doit porter sur le bon niveau de découplage, pas sur un choix “pour ou contre” le headless.
Les briques techniques qui comptent vraiment
Derrière le mot headless, ce sont les briques concrètes qui font varier le coût et la difficulté du projet. Il faut regarder l’exposition de contenu via REST API ou WPGraphQL, l’authentification via JWT, OAuth ou SSO, les webhooks pour déclencher des rebuilds ou des revalidations, la cache invalidation, la preview des brouillons, la diffusion via CDN ou Edge, et la stratégie de rendu choisie entre SSR, SSG et ISR.
Ces arbitrages n’ont rien d’abstrait. Ils influencent directement trois sujets très visibles pour les équipes : la qualité SEO, l’autonomie éditoriale et la charge de run. C’est souvent ici qu’un projet bascule d’un besoin légitime vers une complexité mal justifiée.
La question qui aide à trancher en atelier
La question la plus utile tient souvent en une phrase : quel usage hors web, mesuré et priorisé, justifie objectivement de doubler la stack ?
Quand la réponse reste vague, théorique ou dépend d’un “on verra plus tard”, le signal mérite d’être pris au sérieux. À l’inverse, quand un produit mobile, une logique offline, un portail métier ou un content hub transverse est déjà identifié, priorisé et budgété, la discussion devient beaucoup plus saine. C’est à partir de là que l’on peut regarder, sans posture dogmatique, ce que le headless change vraiment au quotidien.
Ce que le headless change vraiment – et ce que les slides oublient
Deux stacks, donc deux chaînes de build et deux surfaces d’incident
C’est souvent le premier angle mort. Avec un WordPress headless, vous n’avez pas “un WordPress plus moderne”. Vous avez un back-office, un front, une couche de transport des données, un pipeline de déploiement spécifique, et plusieurs points de synchronisation entre ces éléments.
En pratique, cela veut dire deux chaînes de build, deux déploiements, deux historiques de logs, deux systèmes de dépendances, et davantage d’endroits où une régression peut apparaître. Une mise à jour de plugin peut casser un schéma de données. Une évolution du front peut rendre un bloc inutilisable. Un webhook peut ne plus déclencher la revalidation. Une preview peut fonctionner en staging et échouer en production.
Quand le besoin métier est fort, cette complexité reste défendable. Quand le projet vise seulement à “moderniser l’image technique”, le rapport valeur / coût devient plus difficile à soutenir. Et c’est justement ce qui conduit à regarder plus attentivement ce que l’on perd au passage.
Une partie de l’écosystème WordPress ne suit plus naturellement
WordPress est particulièrement efficace lorsque son back-office, son moteur de rendu et ses extensions fonctionnent ensemble. Dès que le front part ailleurs, une partie de cet écosystème perd de sa valeur immédiate. Les thèmes changent de rôle. De nombreux plugins pensés pour enrichir le rendu natif ne produisent plus le même bénéfice. Les shortcodes, certaines previews, des logiques SEO prêtes à l’emploi, certains builders ou des mécaniques de templating doivent être repensés ou réimplémentés côté front.
Ce n’est pas un défaut du headless. C’est simplement le coût réel du découplage. Et c’est précisément ce coût qu’il faut mettre sur la table avant d’aborder le sujet de l’autonomie éditoriale.
Autonomie éditoriale : le paradoxe découvert trop tard
Sur le papier, une stack moderne est souvent associée à plus de liberté. Dans les faits, lorsque le système de blocs, la preview, la gestion des variantes et la logique de composition ne sont pas pensés dès la conception, l’autonomie éditoriale recule.
C’est un point sensible, parce que beaucoup d’équipes marketing attendent l’inverse : plus de fluidité, plus de souplesse et moins de dépendance aux développeurs. Si un headless pur fait perdre une partie de ce bénéfice, la tension apparaît très vite dans les usages, parfois dès les premières semaines.
Un cas classique illustre bien cette situation. Un site corporate international avait été lancé avec un front découplé pour gagner en modernité perçue et en performance. Le discours initial promettait une meilleure maîtrise du rendu et plus de latitude côté produit. Dans les faits, la preview était incomplète, l’édition de pages composites demandait des arbitrages techniques, et chaque évolution de bloc repassait par l’équipe front. Lors de la refonte suivante, le projet est revenu vers une approche plus hybride : WordPress pour le web éditorial, APIs pour quelques usages spécifiques. Ce retour n’a pas été vécu comme un recul, mais comme une reprise en main plus pragmatique. Ce type de trajectoire rappelle que la meilleure architecture n’est pas la plus ambitieuse sur le papier, mais celle qui reste utile dans la durée.
Pour qui cela vaut le coup : les quatre bons cas d’usage
1. Des usages multi-canaux réels
Le premier bon cas est celui où le contenu ne vit plus uniquement sur un site web. Application mobile, écran embarqué, borne, portail partenaire, moteur de recherche fédéré ou interface interne : dans ce contexte, WordPress peut devenir un content hub tout à fait pertinent.
La logique est assez simple. Plus le contenu doit être réutilisé dans plusieurs expériences, plus la séparation du back-office et du front devient défendable. L’important, ici, est que cette réutilisation soit réelle et priorisée, pas simplement évoquée comme une possibilité future.
2. Des contraintes offline ou mobile fortes
Le headless devient cohérent lorsqu’il faut gérer de la synchronisation, du cache embarqué, des connexions dégradées, des expériences app-like ou une logique produit dans laquelle le site web n’est qu’un canal parmi d’autres. Dans ce cas, WordPress n’est pas le moteur de l’expérience ; il devient un point d’orchestration de contenu au service d’un ensemble plus large.
3. Des apps métiers ou un content hub intégré au SI
C’est souvent l’un des cas les plus solides côté grands comptes. WordPress alimente un environnement plus vaste : SSO, annuaire d’entreprise, DAM, PIM, CRM, ERP, outils métiers, analytics ou automation. Ici, le sujet n’est pas d’afficher une architecture plus moderne, mais de construire un point d’édition robuste, gouverné et proprement relié au reste du système d’information.
Dans ce type de projet, ce qui surprend souvent les équipes n’est pas tant la partie CMS que la coordination transverse : règles d’authentification, qualité des données, responsabilités entre équipes, ordre des synchronisations, tolérance à la latence. Ce sont aussi ces zones-là qui coûtent plus cher que prévu si elles ne sont pas cadrées dès le départ.
4. Un produit média à gabarits fermés
Un média ou une plateforme éditoriale avec des gabarits très cadrés, une publication industrialisée, peu de liberté pixel par pixel et une forte exigence de diffusion peut être un bon candidat. À condition d’assumer que la liberté éditoriale n’est pas le besoin principal.
Dans ce cadre, le headless fonctionne mieux lorsque l’organisation accepte de normer les formats et de limiter les écarts de mise en page. Ce qui compte, ce n’est donc pas seulement le volume éditorial, mais le niveau réel de standardisation que les équipes sont prêtes à tenir.
Les signaux qui confirment que le cas d’usage est solide
Quand un projet réunit plusieurs de ces éléments en même temps, le headless ou l’hybride deviennent plus crédibles : un contenu réellement distribué sur plusieurs canaux, un usage mobile ou offline substantiel, des intégrations SI structurantes, des gabarits éditoriaux que l’on peut encadrer sans créer trop de frustration, et une équipe prête à exploiter une architecture plus exigeante dans la durée.
Un retour terrain typique aide à l’illustrer. Sur un projet multi-canal mêlant portail métier et application compagnon, le plus grand décalage n’est pas venu du build initial, mais du nombre de décisions laissées ouvertes trop longtemps : qui déclenche les revalidations, quel niveau de fraîcheur de contenu est réellement attendu, qui possède les contrats d’API, et comment la QA se répartit entre les canaux. Ce qui coûte cher, dans ces projets, n’est pas seulement la technique. C’est le flou entre les équipes.
Quand il vaut mieux ne pas y aller : les red flags
“On veut juste un site plus rapide”
C’est rarement un motif suffisant. Un site WordPress lent n’a pas automatiquement besoin d’un front découplé. Dans beaucoup de projets, le vrai sujet se situe ailleurs : HTML trop lourd, CSS mal gouverné, JavaScript en surpoids, images mal traitées, budget de performance absent, trop de plugins mal choisis, ou rendu global mal maîtrisé.
Autrement dit, le headless ne remplace pas une discipline de performance. Il peut même donner l’impression d’avoir réglé le problème au début, puis le faire réapparaître sous une autre forme côté front. Avant de doubler la stack, il est souvent plus pertinent de vérifier ce qu’un WordPress bien conçu peut déjà produire.
Aucun usage hors web identifié
C’est le critère le plus simple. Lorsqu’il n’existe pas d’usage hors web réel, l’investissement est rarement justifié. Non par principe, mais parce que les coûts supplémentaires créent trop peu de valeur.
Le décalage observé le plus souvent est celui d’un discours d’innovation très fort, alors que le périmètre produit reste celui d’un site corporate, éditorial ou B2B assez classique. Dans ce cas, un WordPress bien gouverné ou une approche hybride ciblée apportent souvent un meilleur équilibre.
L’autonomie éditoriale et Gutenberg sont des priorités
Si l’objectif stratégique consiste à fluidifier les contributions, accélérer les mises en ligne, réduire la dépendance aux développeurs et rendre le marketing plus autonome, un headless pur peut devenir contre-productif.
Ce n’est pas systématique, mais c’est fréquent. Une implémentation mal pensée aggrave précisément les douleurs que l’organisation voulait réduire. D’où l’intérêt, à ce stade, de traiter franchement quelques idées reçues qui reviennent souvent dans les arbitrages.
Mini-FAQ anti-effet de mode
“Tout le monde passe sur Next.js.”
Pas vraiment. Beaucoup d’équipes l’évaluent, certaines y gagnent, d’autres en reviennent, et une large part des projets n’en a pas besoin. La popularité d’un framework n’est pas, en soi, un argument d’architecture.
“Le headless est plus sécurisé.”
Pas automatiquement. La surface d’attaque se redistribue ; elle ne disparaît pas. La sécurité dépend surtout de la qualité d’implémentation, de l’authentification, du cloisonnement, du patching, du monitoring et des pratiques d’exploitation.
“Google aime le JavaScript.”
Google sait traiter du JavaScript, ce qui est très différent de “Google le préfère”. En SEO, la vraie question est de garantir un rendu fiable, rapide, crawlable, bien balisé et stable dans le temps.
Objection fréquente côté CTO ou direction produit : “Au moins, avec un front découplé, on sera plus libres ensuite.”
La réponse terrain est souvent plus nuancée : oui, un découplage peut donner plus de liberté produit, mais seulement si cette liberté correspond à un besoin déjà identifié et si l’organisation a les moyens de l’exploiter. Sinon, on introduit surtout plus de coordination, plus de QA et plus de dépendances croisées, sans bénéfice immédiatement perceptible pour les utilisateurs.
SEO et headless : le piège classique
Headless ne veut pas dire SEO automatique
C’est l’un des raccourcis les plus coûteux. Le SEO d’un WordPress headless ne vient pas avec la stack. Il dépend de choix très précis : mode de rendu, structure de routing, gestion des canonicals, génération des sitemaps, données structurées, pagination, hreflang si besoin, gestion des erreurs, cohérence des URLs, maillage interne et pilotage des revalidations.
Un projet headless peut donc offrir une excellente expérience de développement tout en créant un dispositif SEO fragile. Et c’est précisément pour cela que le sujet du rendu mérite d’être regardé de près.
SSR, SSG, ISR : même promesse apparente, impacts très différents
Le SSR rend la page côté serveur à la demande. Cela peut être très confortable pour le rendu initial et la cohérence SEO, mais cela demande une vraie vigilance sur l’infrastructure, les temps de réponse, la montée en charge et l’observabilité.
Le SSG génère les pages à l’avance. C’est souvent très stable et très performant, à condition de bien gérer la fraîcheur du contenu, les volumes de pages et les temps de build.
L’ISR, souvent présenté comme le compromis idéal, tient cette promesse seulement lorsque les mécanismes de webhooks, de cache invalidation, de purge CDN et de monitoring sont cadrés avec soin. Sinon, il ajoute une subtilité opérationnelle qui se paie le jour où un contenu ne se rafraîchit pas comme prévu.
La vraie question n’est donc pas “quel rendu est le plus moderne ?”, mais “quel rendu garantit le meilleur équilibre entre fraîcheur du contenu, stabilité SEO et charge d’exploitation ?”.
La preview éditoriale : le sujet qui fait souvent déraper les budgets
La preview n’est pas un confort secondaire. C’est un point de rencontre entre éditorial, produit, sécurité et architecture. En headless, il faut penser le mode brouillon, les environnements, le partage d’aperçus, les permissions, les liens temporaires, la cohérence visuelle avec la version publiée, parfois le multi-domaine ou le multi-langue.
Dans de nombreux projets, c’est l’un des postes les plus sous-estimés, simplement parce qu’il n’apparaît pas en premier dans les présentations d’avant-vente.
On voit bien ce phénomène dans les projets mobile ou offline qui veulent conserver un enjeu SEO fort côté web. Une architecture pensée au départ pour du statique peut finir par imposer du SSR sur certaines zones, afin de garantir un HTML fiable, des métadonnées cohérentes et une fraîcheur suffisante. Dès lors, l’infrastructure change, le pipeline se complexifie, le monitoring doit s’étoffer, et la chaîne de preview devient plus sensible. Ce n’est pas un problème en soi ; cela le devient surtout lorsqu’on l’apprend trop tard.
Combien ça coûte : build, run, et surtout ce qu’on oublie
Pourquoi le build est mécaniquement plus cher
Le build coûte plus cher pour une raison simple : il faut construire davantage de choses. Un front sur mesure, une couche de consommation des données, parfois un schéma GraphQL, des règles de preview, un hébergement dédié, une CI/CD plus riche, une stratégie de cache, davantage de QA, plus de tests de non-régression, et des arbitrages supplémentaires sur le SEO technique.
Ce surcoût ne relève pas d’un effet de marge. Il correspond à du travail réel. La question utile n’est donc pas de savoir si le headless coûte plus cher, mais si ce surcoût achète un avantage produit tangible.
Le repère utile : un écart sensible dès la phase de build
Comme ordre de grandeur, un projet headless sérieux démarre généralement au-dessus d’un projet WordPress classique, souvent avec un différentiel sensible dès le build. Une base de discussion autour de +30 % peut servir de repère initial, à condition de la traiter comme un minimum contextuel et non comme une règle universelle.
Dès que l’on ajoute une preview avancée, de l’authentification, plusieurs environnements, une logique multi-canal ou des intégrations SI, l’écart grimpe vite. La bonne posture n’est donc pas de promettre un chiffre simple, mais d’expliquer ce qui fait réellement varier le budget.
La maintenance : là où l’addition devient sérieuse
Le vrai sujet n’est pas uniquement le build. C’est le run. Il faut maintenir WordPress, le front, les dépendances JavaScript, les mécanismes d’authentification, les pipelines, les certificats, les logs, le monitoring, les alertes, les tests end-to-end, les performances, les règles de purge, les intégrations SI et parfois les schémas de données.
Ce n’est pas la création initiale qui fait regretter un choix mal cadré. C’est la répétition de petites opérations d’exploitation qui deviennent structurellement plus coûteuses.
Les coûts cachés à mettre sur la table dès le cadrage
Les postes les plus souvent sous-estimés sont rarement spectaculaires isolément, mais ils finissent par peser lourd ensemble : double monitoring, double roadmap technique, preview et draft mode, auth et SSO, webhooks, cache invalidation, purge CDN, QA cross-canal, surveillance SEO technique, cohérence de tracking, gestion des environnements, alerting et diagnostic d’incident.
Un bon réflexe consiste à raisonner par intensité de projet. Une approche hybride raisonnable reste souvent la zone la plus saine lorsque le web reste central et que quelques usages hors web existent réellement. Un headless plus ambitieux commence à coûter nettement plus dès qu’il faut une vraie preview, une exigence SEO élevée, un design system riche et une exploitation sérieuse. Et un headless multi-canal relié au SI change d’ordre de grandeur, parce qu’on ne finance plus seulement un site, mais une architecture éditoriale connectée à des produits, des flux et des identités.
Un exemple de poste oublié revient souvent : la QA cross-canal. Sur le papier, l’architecture semble propre. Dans la réalité, chaque évolution de contenu ou de composant doit parfois être vérifiée sur le site, dans l’application, dans la preview, et sur plusieurs états de cache. Ce coût n’apparaît pas toujours en premier dans les ateliers de cadrage, alors qu’il devient très visible en run.
L’alternative la plus saine dans beaucoup de cas : obtenir l’effet headless sans doubler la stack
Chercher la qualité de rendu, pas la complexité pour elle-même
Dans de nombreux projets, le besoin réel n’est pas de “faire du headless”. Le besoin réel est d’obtenir un site plus rapide, plus propre, plus maintenable, plus sobre côté JavaScript, plus rigoureux sur le HTML, plus stable sur les Core Web Vitals, avec une gouvernance plugin plus exigeante.
Cette promesse peut souvent être atteinte sur un WordPress bien conçu, sans dissocier le front.
Ce que l’on conserve, et c’est loin d’être secondaire
On conserve Gutenberg, l’écosystème WordPress, les workflows éditoriaux natifs, une preview plus naturelle, une appropriation plus rapide par les équipes marketing et un coût de run plus lisible.
Ce point compte beaucoup. Dans la durée, une architecture utile est rarement celle qui impressionne le plus au départ ; c’est celle que les équipes comprennent, utilisent et maintiennent sans friction excessive.
Ce que cela demande malgré tout
Cette alternative n’a rien de magique. Elle suppose de la rigueur : design system, composants propres, budget de performance, discipline CSS et JavaScript, revue de plugins, CI qualité, métriques de rendu, arbitrages clairs entre confort éditorial et sobriété technique.
Un retour terrain typique illustre bien cette voie. Sur un projet de refonte éditoriale, les gains de performance les plus nets n’ont pas été obtenus par un découplage, mais par une remise à plat des composants, une réduction drastique des plugins à responsabilité floue, un encadrement strict des scripts tiers, et une meilleure hygiène de rendu. Le bénéfice ne s’est pas vu seulement sur les métriques. Il s’est vu aussi sur le run : moins d’effets de bord, moins de dépendances croisées, et une exploitation plus lisible.
C’est souvent là que se joue la vraie sophistication : non pas dans l’ajout d’une seconde stack, mais dans la capacité à produire un WordPress exigeant sans le rendre fragile.
Décider en 60 secondes : la matrice GO / NO-GO
Le headless ou l’hybride deviennent pertinents lorsque plusieurs signaux sont présents en même temps : un besoin multi-canal réel, des contraintes offline ou mobile substantielles, ou une logique de content hub connecté au SI. Quand ces signaux sont réunis, l’architecture peut devenir un levier produit et non un simple choix d’implémentation.
À l’inverse, deux signaux doivent immédiatement ralentir la décision : l’absence d’usage hors web et une recherche de performance comme motivation quasi unique. Dans ce cas, l’expérience montre qu’un meilleur ROI se trouve souvent dans un WordPress bien gouverné, une intégration front propre, une vraie discipline de performance et un cadrage SEO plus rigoureux.
La recommandation la plus solide pour 2026 reste donc assez simple : hybride par défaut. WordPress et Gutenberg pour le web, headless pour les usages hors web qui le justifient réellement. Le headless pur reste un bon choix dans certains contextes, mais surtout lorsque le bénéfice produit est clair, mesurable, et supérieur au coût organisationnel qu’il introduit.
Pour finir
Le vrai sujet n’est pas de savoir si le headless est meilleur. Le vrai sujet est de savoir si votre architecture sert réellement votre produit, votre organisation et votre capacité à tenir la promesse dans le temps.
C’est là qu’une expertise utile fait la différence : non pas en poussant une mode, mais en aidant à cadrer un choix qui restera défendable dans deux ans, au moment du run, des arbitrages budgétaires et de la prochaine refonte.
Une bonne prochaine étape consiste souvent à poser le sujet en atelier d’architecture, avec un objectif simple : repartir non pas avec une conviction abstraite, mais avec une décision argumentée, un macro-chiffrage build et run, et une vision claire des risques réellement assumés.
Si vous êtes en train d’arbitrer entre WordPress classique, hybride ou headless, c’est précisément à ce moment qu’un cadrage extérieur peut faire gagner du temps – et éviter un mauvais niveau de complexité dès le départ.
Mini glossaire utile
SSR
Rendu serveur à la demande. Il est utile lorsqu’il faut servir immédiatement un HTML exploitable, avec une vigilance forte sur l’infrastructure.
SSG
Pages générées à l’avance. C’est souvent une option très stable et performante, à condition de bien gérer la fraîcheur du contenu.
ISR
Compromis entre génération statique et mise à jour progressive. C’est puissant, mais plus subtil à exploiter dans la durée.
REST API
Interface standard pour exposer les contenus WordPress à d’autres applications.
GraphQL / WPGraphQL
Approche de requêtage permettant de demander précisément les données utiles, souvent pertinente lorsque le front a des besoins fins.
Revalidation
Mécanisme qui permet de rafraîchir une page ou un contenu sans reconstruire tout le site.
