Votre déploiement se termine et 12 000 pages statiques arrivent au CDN. Aucun serveur ne démarre. Aucune requête à la base de données ne se déclenche en cours de traitement. C'est rapide, versionné, et ça coûte 19 $/mois à héberger — exactement la promesse que Netlify vous a vendue en 2019 quand ils ont inventé « Jamstack ». Mais en 2026, plus personne n'appelle ça comme ça. L'architecture a survécu. La marque non. Ce que vous regardez n'est pas une mort — c'est une mutation. Gatsby s'est effondré en mode maintenance. Next.js a absorbé la moitié de l'écosystème et a pivoté vers React Server Components. Astro a livré son architecture d'îles et a appelé la génération statique « des defaults évidents ». Les modèles sur lesquels vous comptiez se sont fragmentés en rendu server-first, compute à la périphérie, et hydratation sélective. Le label est mort parce que la chose qu'il décrivait s'est divisée en cinq philosophies concurrentes, chacune prétendant faire Jamstack mieux en n'étant pas Jamstack du tout.

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

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

Table of Contents

Is Jamstack Dead in 2026? An Honest Assessment of What Changed

Ce que Jamstack signifiait réellement

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

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éparez votre frontend de votre backend/CMS
  3. CDN-first : Servez tout depuis la périphérie
  4. Piloté par API : Gérez les fonctionnalités dynamiques via des APIs et des fonctions serverless

L'engagement philosophique clé était que le temps de compilation est mieux que le temps de requête. Vous faites le travail lourd une fois pendant le déploiement, et chaque visiteur obtient le résultat en cache.

Cela a fonctionné brillamment pour les blogs, les sites marketing, la documentation et les pages de produits e-commerce. Cela a fonctionné terriblement pour tout ce qui avait besoin de personnalisation, de données en temps réel ou de contenu qui changeait toutes les quelques minutes.

La chronologie du déclin

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

Année Événement Impact
2020 Gatsby lève 28 M$ Series 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 le default
2023 Netlify acquiert Gatsby, puis l'abandonne essentiellement Fin symbolique du Jamstack « pur »
2024 Astro 4.x gagne une traction majeure, Vercel pousse PPR La génération statique persiste sous de nouvelles formes
2025 Next.js 15 livré avec des modèles RSC matures Server-first devient le default mainstream
2026 Le terme « Jamstack » apparaît rarement dans les listes d'emplois 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 plus une acqui-hire qui s'est progressivement arrêtée.

Mais blâmer le déclin de Gatsby sur le fait que « Jamstack meurt » manque l'essentiel. 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 passif. 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 a offert plus de flexibilité.

Où Jamstack a gagné (définitivement)

Voici ce que je pense que les gens se trompent dans le narratif « Jamstack est mort » : les idées fondamentales ont gagné si complètement que nous avons cessé de les remarquer.

L'architecture découplée est le default

La plus grande victoire de Jamstack est que les frontends découplés sont maintenant la norme pour tout projet web sérieux. En 2018, vous deviez argumenter 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 CMS headless et quel framework frontend ? »

Ceci est un changement architectural permanent. Personne ne revient aux templates PHP monolithiques pour les nouveaux projets (la maintenance héritée est une autre histoire). Le modèle headless — que vous l'appeliez Jamstack ou non — a gagné.

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

Livraison CDN-First

Chaque framework majeur et plateforme d'hébergement priorise maintenant la livraison par périphérie. Vercel, Cloudflare, Netlify, AWS — ils supposent tous que votre contenu devrait être aussi proche que possible de l'utilisateur. C'était un principe Jamstack avant que ce soit un default de l'industrie.

Flux de travail basés sur Git

L'idée que votre site se déploie à partir d'un git push, passe par CI/CD, et arrive 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 comme outil (pas une religion)

SSG n'est pas mort. C'est devenu un outil parmi tant 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.

Is Jamstack Dead in 2026? An Honest Assessment of What Changed - architecture

Où Jamstack a perdu

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

Les temps de compilation étaient un vrai problème

Le secret honteux des grands sites Jamstack était les temps de compilation. J'ai travaillé sur un projet avec 40 000 pages de produits en 2021. Reconstruction complète ? 45 minutes. Même avec les compilations incrémentielles, tout changement de schéma signifiait recommencer. Quand vos éditeurs de contenu doivent attendre 20 minutes pour voir un changement 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éponses directes à ce problème. Ils ont reconnu que la pré-construction de tout au moment de la compilation n'échelle 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. À partir du moment où vous avez besoin de contenu spécifique à l'utilisateur — états connectés, recommandations personnalisées, tests A/B, tarification géociblée — vous combattez l'architecture. La récupération côté client crée un layout shift. Le middleware de périphérie ajoute de la complexité. Vous finissez par construire une application rendue côté serveur avec des étapes supplémentaires.

Le « J » dans Jamstack est devenu enflé

Les tailles de bundle JavaScript sur les sites Jamstack ont échappé à tout contrôle. Les sites Gatsby expédiaient régulièrement 300-500KB de JavaScript pour ce qui était essentiellement un blog. Le HTML statique était rapide, mais ensuite l'étape d'hydratation bloquerait 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é en tant que réactions directes à ce problème d'inflation de JavaScript.

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

Les éditeurs de contenu habitués à WordPress ont eu du mal avec Jamstack. Vous changeriez un en-tête dans votre CMS, déclencheriez un webhook, attendriez une compilation, et peut-être verriez alors 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'émergence des Server Components et du rendu hybride

React Server Components (RSC) représentent le plus grand changement philosophique en architecture frontend depuis l'ère du SPA. Et ils sont fondamentalement en contradiction 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 tout pré-construire, vous rendez les composants sur le serveur, streamez du HTML au client, et envoyez zéro JavaScript pour les composants qui n'ont pas besoin d'interactivité.

Cela retourne le scénario Jamstack. Au lieu de « construire tout à l'avance et servir des fichiers statiques », c'est « rendez à la demande mais soyez intelligent sur ce qui a besoin de JavaScript ».

Les résultats parlent d'eux-mêmes. Une application RSC bien construite peut égaler ou surpasser 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 solutions de contournement Jamstack.

// Un composant serveur dans Next.js App Router — aucun JS client-side 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 KB envoyé au navigateur. */}
      <ReviewsList reviews={reviews} />
      {/* Seul ce composant interactif expédie 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 de produit, puis récupéreriez les avis côté client, puis hydrateriez 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 compilation
  • Rendu côté serveur (SSR) : Pages rendues par requête
  • Incremental Static Regeneration (ISR) : Pages statiques qui se revalident selon un planning
  • Partial Prerendering (PPR) : Shells statiques avec trous rendus côté serveur
  • Rendu côté client : Pour les composants purement interactifs

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

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

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

Notre pratique de développement Next.js s'est fortement déplacée vers ces modèles 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'époque Jamstack pure.

La décision au niveau du framework s'est déplacée de « statique ou dynamique » à « quelle stratégie de rendu chaque morceau de contenu a-t-il besoin ? » C'est une conversation plus mature.

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

Si vous voulez argumenter 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 vous optez pour l'interactivité seulement où vous en avez besoin.

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

  • Une page de blog Astro typique expédie 0 KB de JavaScript sauf si vous ajoutez explicitement des composants interactifs
  • Les temps de compilation sont rapides car Astro ne bundle pas un runtime React complet
  • Content Collections fournissent une couche de contenu type-safe sans complexité GraphQL
  • Vous pouvez utiliser des composants React, Vue, Svelte ou HTML brut — choisissez votre poison
---
// Ceci est un composant Astro. Il s'exécute au moment de la compilation uniquement.
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 JavaScript */}
    <SearchWidget client:load />
  </body>
</html>

Les server islands d'Astro (introduites en fin de 2024) ont ajouté la capacité d'avoir des composants rendus côté serveur dynamiques dans des pages autrement statiques — arrivant essentiellement à une destination similaire à celle de Next.js PPR mais depuis la direction static-first.

Nous avons de plus en plus recours à Astro dans nos travaux de développement Astro pour les sites marketing, la documentation et les projets riches en contenu où les performances sont prioritaires et les besoins d'interactivité sont modestes.

Feature Next.js (App Router) Astro 5.x Old 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 compilation (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 Hacky au mieux
Intégration CMS Excellente Excellente Dépendante des plugins
Courbe d'apprentissage Raide (modèle RSC) Modérée Modérée-Haute
Meilleur pour Apps + contenu hybride Sites content-first Blogs (historiquement)

La couche Headless CMS : plus forte que jamais

Voici le truc qui me fait réagir le plus fortement contre la narration « Jamstack est mort » : le marché des CMS headless est en plein essor. Si l'architecture était vraiment morte, son infrastructure de contenu ne serait pas en train de prospérer.

Le marché des CMS headless était évalué à environ 2,1 milliards de dollars en 2024 et devrait atteindre 5,5 milliards de dollars 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 CMS headless en entreprise, avec des fonctionnalités de composabilité améliorées en 2025
  • Sanity a crû rapidement avec son édition collaborative en temps réel et son langage de requête GROQ
  • Storyblok s'est taillé une part 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é une 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 CMS headless ne se soucie pas si votre frontend utilise la génération statique, les composants serveur ou les pigeons voyageurs. Il fournit du contenu structuré via les 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 l'architecture moderne en 2026

Alors si nous n'appelons pas ça 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 beaucoup. L'industrie n'a pas réglé un terme, ce qui est probablement bien. Nous n'avons pas besoin d'un label marketing pour une bonne architecture.

Voici à quoi ressemble un projet typique en 2026 :

Couche de contenu : Un CMS headless (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 content-first. 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 utilisateurs 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 compilation : CI/CD basée 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 l'essentiel.

Les décisions architecturales que nous aidons les clients à prendre lors de nos engagements de développement CMS headless reflètent cette réalité hybride. Il n'y a pas de stratégie de rendu 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 évaluez 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 beaucoup « Jamstack » dans de nombreuses listes d'emplois ou RFP maintenant. Mais les principes architecturaux fondamentaux (frontends découplés, livraison CDN, contenu piloté par API, flux de travail basés sur git) sont plus répandus que jamais. Ils ont été absorbés par le développement web dominant si profondément qu'ils n'ont pas besoin d'un label séparé. Gatsby spécifiquement est mort. La philosophie persiste.

Qu'est-ce qui 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 pure de génération statique. Ces frameworks vous permettent de choisir la bonne stratégie de rendu par page ou même par composant — statique, rendu côté serveur ou côté client. Le modèle architectural headless (CMS découplé + framework frontend + hébergement edge) reste le standard ; il ne porte juste plus le label Jamstack.

La génération de sites statiques est-elle encore pertinente en 2026 ?

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

Que s'est-il passé avec Gatsby ?

Gatsby a été acquis par Netlify début 2023 et a été effectivement discontinué. Sa dernière mise à jour significative a eu lieu en 2023. L'écosystème s'est effondré alors que les mainteneurs de plugins passaient à d'autres choses et que la communauté migrait vers Next.js, Astro et d'autres frameworks. Les problèmes fondamentaux de Gatsby — temps de compilation 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.

Dois-je toujours utiliser un CMS headless en 2026 ?

Oui, et le marché pour les plateformes CMS headless est plus fort que jamais. Contentful, Sanity, Storyblok, Payload CMS et autres se sont tous considérablement maturés. Le découplage des CMS headless a été 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 lock-in fournisseur à une plateforme monolithique. À moins que vous construisiez un blog personnel (où les fichiers markdown vont bien), un CMS headless vaut l'investissement.

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

RSC a fondamentalement changé le default de « pré-rendre au moment de la compilation » à « rendre sur le serveur au moment de la requête ». Les composants serveur s'exécutent sur le serveur, n'expédient zéro JavaScript au navigateur et peuvent accéder directement aux bases de données et aux APIs. Cela élimine de nombreuses solutions de contournement que Jamstack nécessitait pour le contenu dynamique — plus de récupération côté client, de spinners de chargement ou de layout shift pour les données que le serveur aurait pu inclure dans la réponse initiale. RSC a rendu le rendu côté serveur aussi ergonomique que la génération statique.

Vaut-il 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 principalement statique, les compilations sont assez rapides et vous n'avez pas besoin de personnalisation — il n'y a pas de raison urgente de migrer. Si vous combattez les temps de compilation, ajoutez une récupération de données côté client de plus en plus complexe ou avez des difficultés avec les flux de travail d'aperçu, le modèle de rendu hybride d'App Router vaut probablement le coût de la migration. La courbe d'apprentissage pour RSC et App Router est réelle, alors tenez-en compte 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, compilations rapides, DX excellente et excellentes intégrations CMS headless. Pour les sites qui mélangent contenu et fonctionnalités d'application (e-commerce, comptes utilisateur, tableaux de bord), Next.js vous offre 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.