Je construis des sites Jamstack depuis 2018. À l'époque, le pitch était irrésistible : pré-rendre tout en HTML statique, le servir depuis un CDN, et ajouter des APIs pour les fonctionnalités dynamiques. C'était rapide, sécurisé et bon marché à héberger. Netlify a inventé le terme, Gatsby a surfé sur la vague de hype, et pendant un moment, cela semblait être l'avenir du développement web.

Maintenant, nous sommes en 2026, et la conversation a radicalement changé. Les serveurs Discord de Jamstack sont plus calmes. Gatsby est effectivement mort. Netlify a licencié une part importante de son effectif. Et pourtant — et c'est la partie que les gens ratent — les idées derrière Jamstack sont partout. Elles ne portent simplement plus cette étiquette.

Alors, Jamstack est-il mort ? La réponse honnête est compliquée, et je pense que la nuance importe plus que le hot take.

Table des matières

Jamstack est-il mort en 2026 ? Une évaluation honnête de ce qui a changé

Ce que Jamstack signifiait réellement

Soyons précis sur les définitions, car beaucoup du discours « Jamstack est mort » souffre de gens qui débattent de choses différentes.

Le Jamstack original (JavaScript, APIs, Markup) avait quelques principes fondamentaux :

  1. Pré-rendu : Générer du HTML au moment de la construction, pas au moment de la requête
  2. Découplage : Séparer votre frontend de votre backend/CMS
  3. CDN en premier : Servir tout depuis le bord
  4. Piloté par API : Gérer la fonctionnalité dynamique via des APIs et des fonctions serverless

L'engagement philosophique clé était que le temps de construction est meilleur que le temps de requête. Vous faites le travail lourd une seule fois lors du déploiement, et chaque visiteur obtient le résultat mis en cache.

Cela fonctionnait brillamment pour les blogs, les sites marketing, la documentation et les pages de produits de commerce électronique. Cela fonctionnait terriblement pour tout ce qui nécessitait de la personnalisation, des données en temps réel ou du contenu qui changeait toutes les quelques minutes.

La chronologie du déclin

Voici à peu près comment le récit Jamstack s'est effondré :

Année Événement Impact
2020 Gatsby lève 28 millions de dollars en Série C Pic du hype Jamstack
2021 Next.js introduit ISR (Incremental Static Regeneration) Brouille la ligne entre statique et dynamique
2022 React Server Components annoncés Changement de paradigme vers le rendu serveur
2023 Next.js App Router devient stable, l'utilisation de Gatsby s'effondre Le rendu hybride devient par défaut
2023 Netlify acquiert Gatsby, puis l'abandonne essentiellement Fin symbolique du Jamstack « pur »
2024 Astro 4.x gagne en traction majeure, Vercel pousse PPR La génération statique persiste sous de nouvelles formes
2025 Next.js 15 est livré avec des patterns RSC matures Server-first devient la norme principale
2026 Le terme « Jamstack » apparaît rarement dans les offres d'emploi ou les RFP La marque est morte, les principes persistent

L'histoire de Gatsby est particulièrement révélatrice. À son apogée, Gatsby avait des milliers de plugins, une communauté massive et une véritable adoption en entreprise. En 2024, ses téléchargements npm avaient chuté de plus de 80 % par rapport au pic. L'acquisition par Netlify ne l'a pas sauvé — c'était plutôt une acqui-embauche qui s'est discrètement terminée.

Mais blâmer le déclin de Gatsby sur « Jamstack meurt » rate le point. Gatsby a décliné parce qu'il avait de véritables problèmes techniques : des temps de construction absurdement longs, une couche de données alambiquée (GraphQL pour tout, que vous le vouliez ou non), et un écosystème de plugins qui est devenu un handicap. Next.js a mangé le déjeuner de Gatsby non pas parce que la génération statique était mauvaise, mais parce que Next.js l'a fait mieux et offrait plus de flexibilité.

Où Jamstack a gagné (de façon permanente)

Voici ce que je pense que les gens se trompent sur la narrative « Jamstack est mort » : les idées fondamentales ont gagné si complètement que nous avons arrêté de les remarquer.

L'architecture découplée est la norme

La plus grande victoire de Jamstack est que les frontends découplés sont désormais la norme pour tout projet web sérieux. En 2018, vous deviez vous battre pour séparer votre frontend de WordPress ou de votre CMS. En 2026, la question n'est pas « devrions-nous découpler ? » — c'est « quel headless CMS et quel framework frontend ? »

C'est un changement architectural permanent. Personne ne revient aux modèles PHP monolithiques pour les nouveaux projets (la maintenance de l'héritage est une histoire différente). Le pattern headless — que vous l'appeliez Jamstack ou non — a gagné.

Nous le voyons constamment dans notre travail de développement de Headless CMS. Les clients ne demandent plus « devrions-nous aller headless ? ». Ils demandent quel headless CMS convient à leur modèle de contenu.

Livraison CDN en premier

Chaque framework majeur et plateforme d'hébergement priorise maintenant la livraison au bord. Vercel, Cloudflare, Netlify, AWS — ils supposent tous que votre contenu devrait être aussi près que possible de l'utilisateur. C'était un principe Jamstack avant d'être une norme industrielle.

Workflows basés sur Git

L'idée que votre site se déploie à partir d'un git push, passe par CI/CD, et atterrit sur une URL d'aperçu avant de frapper la production ? C'était radical en 2017. C'est table stakes maintenant. Chaque plateforme frontend l'offre. Jamstack l'a normalisé.

Génération statique en tant qu'outil (pas une religion)

SSG n'est pas mort. C'est devenu un outil parmi d'autres. Chaque framework majeur — Next.js, Astro, Nuxt, SvelteKit — supporte la génération statique. La différence est que c'est maintenant un choix par page plutôt qu'une architecture tout ou rien.

Jamstack est-il mort en 2026 ? Une évaluation honnête de ce qui a changé - architecture

Où Jamstack a perdu

Être honnête signifie reconnaître aussi les vrais échecs.

Les temps de construction étaient un vrai problème

Le secret honteux des grands sites Jamstack était les temps de construction. J'ai travaillé sur un projet avec 40 000 pages de produits en 2021. Reconstruction complète ? 45 minutes. Même avec les builds incrémentiels, tout changement de schéma signifiait recommencer. Quand vos éditeurs de contenu doivent attendre 20 minutes pour voir un changement sur le site en direct, vous avez perdu l'argument sur l'expérience développeur.

ISR et la revalidation à la demande dans Next.js ont été des réactions directes à ce problème. Ils ont reconnu que pré-rendre tout au moment de la construction ne s'adapte pas au-delà d'un certain point.

La personnalisation a toujours été un hack

Les sites Jamstack sont excellents quand tout le monde voit le même contenu. Au moment où vous avez besoin de contenu spécifique à l'utilisateur — états connectés, recommandations personnalisées, tests A/B, tarification ciblée par géolocalisation — vous vous battez contre l'architecture. La récupération côté client crée un changement de mise en page. Les middleware en bordure ajoutent de la complexité. Vous finissez par construire une app avec rendu serveur avec des étapes supplémentaires.

Le « J » dans Jamstack est devenu gonflé

Les tailles de bundle JavaScript sur les sites Jamstack sont devenues incontrôlables. Les sites Gatsby expédiaient régulièrement 300-500 Ko de JavaScript pour ce qui était essentiellement un blog. Le HTML statique était rapide, mais ensuite l'étape d'hydratation verrouillait le thread principal pendant des secondes sur les appareils mobiles. C'était un propre but.

L'architecture d'îles d'Astro et les server components ont tous deux émergé comme des réactions directes à ce problème d'inflation JavaScript.

L'expérience d'aperçu et d'édition en a souffert

Les éditeurs de contenu habitués à WordPress avaient une expérience rude avec Jamstack. Vous changiez un titre dans votre CMS, déclenchiez un webhook, attendiez une construction, et peut-être voyiez votre changement. Des outils comme les éditeurs visuels et les modes brouillon ont amélioré les choses, mais l'expérience n'a jamais égalé ce qu'un CMS traditionnel offrait prêt à l'emploi.

L'essor des Server Components et du rendu hybride

React Server Components (RSC) représentent le plus grand changement philosophique en architecture frontend depuis l'ère des SPA. Et ils sont fondamentalement en désaccord avec la pensée Jamstack pure.

Voici pourquoi : RSC suppose que le rendu sur le serveur au moment de la requête est bon, en fait. Au lieu de pré-construire tout, vous rendez les composants sur le serveur, diffusez du HTML au client, et envoyez zéro JavaScript pour les composants qui n'ont pas besoin d'interactivité.

Cela retourne le script Jamstack. Au lieu de « construire tout à l'avance et servir des fichiers statiques », c'est « rendre à la demande mais être intelligent sur ce qui a besoin de JavaScript ».

Les résultats parlent d'eux-mêmes. Une application RSC bien construite peut égaler ou battre le Time to First Byte d'un site statique tout en gérant la personnalisation, les données en temps réel et le contenu dynamique sans aucune des contournements Jamstack.

// Un composant serveur dans Next.js App Router — aucun JavaScript côté client expédié
async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  const reviews = await getReviews(product.id);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Ce composant s'exécute sur le serveur. Zéro Ko envoyé au navigateur. */}
      <ReviewsList reviews={reviews} />
      {/* Seul ce composant interactif expédie du JavaScript */}
      <AddToCartButton productId={product.id} />
    </main>
  );
}

Le modèle mental est plus propre que l'équivalent Jamstack, où vous généreriez statiquement la page du produit, puis récupériez les avis côté client, puis hydratateriez le bouton panier, gérant les états de chargement pour chacun.

Next.js App Router : le tueur de Jamstack ou son évolution ?

Je dirais que c'est les deux. Next.js n'a pas tué Jamstack — il l'a absorbé.

Next.js 15 en 2025 supporte chaque stratégie de rendu que vous pourriez vouloir :

  • Génération statique (SSG) : Pages rendues au moment de la construction
  • Rendu côté serveur (SSR) : Pages rendues par requête
  • Régénération statique incrémentale (ISR) : Pages statiques qui se revalident selon un calendrier
  • Rendu partiellement pré-rendu (PPR) : Coquilles statiques avec des trous dynamiques rendus serveur
  • Rendu côté client : Pour les composants purement interactifs

PPR est particulièrement intéressant. Il pré-rend une coque statique de votre page (la mise en page, la navigation, le contenu statique) et laisse des trous pour le contenu dynamique qui est rendu serveur et diffusé sur chaque requête. C'est comme si Jamstack et SSR avaient un bébé.

// Avec PPR, les parties statiques sont pré-rendues, les parties dynamiques sont diffusées
import { Suspense } from 'react';

export default function DashboardPage() {
  return (
    <main>
      {/* Ceci est pré-rendu au moment de la construction */}
      <h1>Votre tableau de bord</h1>
      <Navigation />
      
      {/* Ceci est diffusé dynamiquement par requête */}
      <Suspense fallback={<DashboardSkeleton />}>
        <PersonalizedContent />
      </Suspense>
    </main>
  );
}

Notre pratique de développement Next.js a fortement glissé vers ces patterns hybrides. La plupart des projets utilisent maintenant un mélange de rendu statique et dynamique sur une base par composant, ce qui aurait été une hérésie à l'ère du Jamstack pur.

La décision au niveau du framework s'est éloignée de « statique ou dynamique » vers « quelle stratégie de rendu chaque pièce de contenu a-t-elle besoin ? » C'est une conversation plus mûre.

Astro et la renaissance de la génération statique

Si vous voulez soutenir que Jamstack est vivant, Astro est votre meilleure preuve.

Astro a pris les meilleures parties de Jamstack — génération statique, JavaScript minimal, rapide par défaut — et a construit un framework qui corrige les pires parties. Son architecture d'îles signifie que vous expédiez zéro JavaScript par défaut et optez pour l'interactivité uniquement où vous en avez besoin.

Pour les sites lourds en contenu, l'approche d'Astro est difficile à battre :

  • Une page de blog typique d'Astro expédie 0 Ko de JavaScript à moins que vous n'ajoutiez explicitement des composants interactifs
  • Les temps de construction sont rapides car Astro ne regroupe pas un runtime React complet
  • Content Collections fournit une couche de contenu type-safe sans complexité GraphQL
  • Vous pouvez utiliser des composants React, Vue, Svelte ou HTML simples — choisissez votre poison
---
// C'est un composant Astro. Il s'exécute uniquement au moment de la construction.
const posts = await getCollection('blog');
---

<html>
  <body>
    <h1>Blog</h1>
    {posts.map(post => (
      <article>
        <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
        <p>{post.data.excerpt}</p>
      </article>
    ))}
    
    <!-- Seule cette île expédie du JavaScript -->
    <SearchWidget client:load />
  </body>
</html>

Les server islands d'Astro (introduites fin 2024) ont ajouté la possibilité d'avoir des composants rendus serveur dynamiques au sein de pages autrement statiques — arrivant essentiellement à une destination similaire à Next.js PPR mais en partant de la direction static-first.

Nous avons de plus en plus recours à Astro dans notre travail de développement Astro pour les sites marketing, la documentation et les projets pilotés par le contenu où la performance est prioritaire et les besoins d'interactivité sont modestes.

Fonctionnalité Next.js (App Router) Astro 5.x Ancien Jamstack (Gatsby)
Rendu par défaut Serveur (RSC) Statique (SSG) Statique (SSG)
JavaScript expédié Par composant Zéro par défaut Runtime React complet
Temps de construction (10k pages) ~3-5 min ~1-2 min ~15-30 min
Contenu dynamique Natif (RSC/SSR) Server islands Récupération côté client
Personnalisation Intégrée Middleware + islands Difficile au mieux
Intégration CMS Excellente Excellente Dépend des plugins
Courbe d'apprentissage Raide (modèle RSC) Modérée Modérée-Élevée
Meilleur pour Applications + contenu hybride Sites piloté par le contenu Blogs (historiquement)

La couche Headless CMS : plus forte que jamais

Voici la chose qui me pousse le plus à contester la narrative « Jamstack est mort » : le marché des headless CMS est en plein essor. Si l'architecture était réellement morte, son infrastructure de contenu ne prospérerait pas.

Le marché des headless CMS a été évalué à environ 2,1 milliards de dollars en 2024 et devrait atteindre 5,5 milliards d'ici 2030 (diverses estimations d'analystes placent le TCAC à 20-25%). Les principaux acteurs affichent tous une croissance solide :

  • Contentful continue de dominer le headless CMS d'entreprise, avec des fonctionnalités de composabilité améliorées en 2025
  • Sanity a grandi rapidement avec son édition collaborative en temps réel et son langage de requête GROQ
  • Storyblok s'est taillé une niche solide avec son éditeur visuel, résolvant le problème d'aperçu qui a tourmenté le Jamstack précoce
  • Payload CMS (open source, auto-hébergé) a gagné en traction sérieuse auprès des développeurs qui veulent le contrôle total
  • Hygraph (anciennement GraphCMS) continue de servir les équipes axées sur GraphQL

Le headless CMS ne se soucie pas si votre frontend utilise la génération statique, les server components ou les pigeons voyageurs. Il fournit du contenu structuré via des APIs. C'est tout. La stratégie de rendu est le problème de votre frontend.

Ce découplage est l'héritage Jamstack le plus durable. Le fait que la couche de contenu et la couche de présentation soient séparées n'est pas une tendance — c'est un principe architectural qui a survécu à la mort de la marque.

À quoi ressemble réellement l'architecture moderne en 2026

Donc si nous n'appelons pas cela Jamstack, comment appelons-nous la façon dont la plupart des sites modernes sont construits ? J'utilise « headless hybride » dans les conversations, bien que je ne l'aime pas vraiment. L'industrie n'a pas réglé de terme, ce qui est probablement bien. Nous n'avons pas besoin d'une étiquette marketing pour une bonne architecture.

Voici à quoi ressemble un projet typique en 2026 :

Couche de contenu : Un headless CMS (Sanity, Contentful, Payload, Storyblok — selon les besoins et le budget)

Framework frontend : Next.js pour tout ce qui a des fonctionnalités d'app ou une interactivité complexe. Astro pour les sites piloté par le contenu. SvelteKit ou Nuxt si l'équipe a ces préférences.

Stratégie de rendu : Mixte. Les pages marketing sont générées statiquement. Les pages de produits utilisent ISR ou PPR. Les tableaux de bord utilisateur utilisent le rendu côté serveur. Les widgets interactifs utilisent le rendu côté client. Le framework gère tout cela.

Hébergement : Plateformes edge-first. Vercel, Cloudflare Pages, Netlify ou AWS (CloudFront + Lambda@Edge) selon l'échelle et le budget.

Processus de construction : CI/CD basé sur git avec déploiements d'aperçu. Revalidation déclenchée par webhook depuis le CMS.

Si vous plissez les yeux, cela ressemble beaucoup à Jamstack avec plus de flexibilité. Et c'est un peu le point.

Les décisions architecturales que nous aidons les clients à prendre lors de nos engagements de développement de Headless CMS reflètent cette réalité hybride. Il n'y a pas de stratégie de rendu taille unique. La bonne réponse dépend du volume de contenu, des besoins de personnalisation, des exigences du flux de travail éditorial et du budget. Si vous pesez ces compromis pour votre propre projet, nous serions heureux d'en discuter.

FAQ

Jamstack est-il mort en 2026 ?

La marque est effectivement morte — vous ne verrez pas « Jamstack » dans beaucoup d'offres d'emploi ou d'appels d'offres maintenant. Mais les principes architecturaux fondamentaux (frontends découplés, livraison CDN, contenu piloté par API, workflows basés sur git) sont plus répandus que jamais. Ils ont été absorbés par le développement web grand public tellement complètement qu'ils n'ont pas besoin d'une étiquette séparée. Gatsby spécifiquement est mort. La philosophie persiste.

Qu'a remplacé Jamstack ?

Les frameworks de rendu hybride comme Next.js (avec App Router et RSC), Astro, Nuxt 3 et SvelteKit ont remplacé l'approche de génération statique pure. Ces frameworks vous permettent de choisir la bonne stratégie de rendu par page ou même par composant — statique, rendu serveur ou côté client. Le pattern d'architecture headless (CMS découplé + framework frontend + hébergement edge) reste la norme ; il ne porte simplement pas l'étiquette Jamstack.

La génération de site statique est-elle toujours pertinente en 2026 ?

Absolument. SSG est toujours le meilleur choix pour le contenu qui ne change pas fréquemment et n'a pas besoin de personnalisation — blogs, documentation, pages marketing, pages de renvoi. Astro est devenu le framework incontournable pour les sites static-first. Next.js et Nuxt supportent toujours SSG comme l'une des options de rendu parmi d'autres. Ce qui a changé, c'est que SSG est maintenant un outil auquel vous avez recours quand c'est approprié, pas une philosophie architecturale entière.

Qu'est-il arrivé à Gatsby ?

Gatsby a été acquis par Netlify au début de 2023 et a été effectivement abandonné. Sa dernière mise à jour significative a eu lieu en 2023. L'écosystème s'est effondré alors que les mainteneurs de plugins ont continué et la communauté a migré vers Next.js, Astro et d'autres frameworks. Les problèmes fondamentaux de Gatsby — temps de construction excessifs, couche de données GraphQL forcée, bundles JavaScript lourds et un système de plugins complexe — n'ont jamais été adéquatement résolus.

Devrais-je toujours utiliser un headless CMS en 2026 ?

Oui, et le marché des plateformes headless CMS est plus fort que jamais. Contentful, Sanity, Storyblok, Payload CMS et d'autres ont tous mûri considérablement. Le découplage du headless CMS était le principe Jamstack le plus durable. Il vous permet de choisir votre frontend indépendamment, de réutiliser le contenu sur les canaux et d'éviter le verrouillage des fournisseurs à une plateforme monolithique. À moins que vous ne construisiez un blog personnel (où les fichiers markdown conviennent), un headless CMS vaut l'investissement.

Comment les React Server Components changent-elles l'équation Jamstack ?

RSC a fondamentalement changé la valeur par défaut de « pré-rendre au moment de la construction » à « rendre sur le serveur au moment de la requête ». Les composants serveur s'exécutent sur le serveur, expédient zéro JavaScript au navigateur et peuvent accéder directement aux bases de données et APIs. Cela élimine de nombreux contournements que Jamstack nécessitait pour le contenu dynamique — plus de récupération côté client, d'indicateurs de chargement ou de changement de mise en page pour les données que le serveur aurait pu inclure dans la réponse initiale. RSC a rendu le rendu serveur aussi ergonomique que la génération statique.

Est-ce que ça vaut la peine de migrer vers Next.js App Router depuis une configuration Jamstack ?

Cela dépend des problèmes que vous résolvez. Si votre configuration statique actuelle gère vos besoins — votre contenu est mostly statique, les constructions sont assez rapides et vous n'avez pas besoin de personnalisation — il n'y a pas de raison urgente de migrer. Si vous vous battez avec les temps de construction, en ajoutant de plus en plus de récupération de données côté client complexe ou en ayant du mal avec les workflows d'aperçu, le modèle de rendu hybride de l'App Router vaut probablement le coût de migration. La courbe d'apprentissage pour RSC et l'App Router est réelle, alors factorisez cela dans votre décision.

Quel est le meilleur framework pour un nouveau site de contenu en 2026 ?

Pour les sites de contenu pur (blogs, docs, marketing), Astro est difficile à battre — zéro JavaScript par défaut, constructions rapides, excellent DX et excellentes intégrations headless CMS. Pour les sites qui mélangent contenu et fonctionnalités d'application (e-commerce, comptes utilisateur, tableaux de bord), Next.js vous donne le plus de flexibilité avec ses options de rendu hybride. Si votre équipe préfère Vue, Nuxt 3 offre des capacités similaires à Next.js. Il n'y a pas de mauvaise réponse parmi ces trois ; le choix dépend de l'expertise de votre équipe et des besoins spécifiques de votre projet.