Jamstack : du static-first au web composable.

Entre 2017 et 2019, la Jamstack était partout. La communauté bouillonnait sous l’impulsion de Netlify et de Mathias Biilmann, son cofondateur, qui a introduit le terme dans un talk à la Smashing Conf en 2016. Contrairement à ce qu’on entend souvent, Netlify n’a pas inventé la Jamstack, ils ont simplement mis un nom sur une tendance qu’ils ont vu arriver dans l’industrie.

Ce terme a cartonné pendant quelques années et a petit à petit disparu des conférences et des articles, jusqu’à devenir anecdotique lorsque des frameworks comme Next ou Nuxt ont amené la possibilité de cumuler du rendu côté serveur et du rendu statique sur le même site. Cela a eu pour effet d’amener une certaine confusion dans la communauté sur ce qui est considéré “Jamstack” et ce qui ne l’est pas, créant des débats enflammés entre les puristes et les gens qui avaient un certain intérêt à vendre des services cloud.

Pourquoi reparler de la Jamstack ?

En 2026, prononcer le mot “Jamstack” c’est s’assurer de passer pour un dinosaure du web qui n’a pas suivi l’actu de l’écosystème frontend ces 7 dernières années. Pourquoi j’ose réveiller des concepts enterrés depuis bien longtemps dans les archives de la Wayback Machine ? Parce que bien que la hype soit retombée et que le mot lui-même soit en voie de disparition, ces concepts ne sont pas morts, bien au contraire : Les architectures frontend modernes lui doivent beaucoup.

Si peu d’équipes revendiquent explicitement une architecture Jamstack aujourd’hui, une grande partie du web en hérite pourtant directement. La Jamstack n’a pas disparu. Elle a été absorbée par les frameworks. Et si ce n’est plus hype de dire “on fait de la Jamstack”, c’est probablement parce qu’elle est en quelque sorte devenue la norme.

Au programme de cet article : 

• Aux origines : Les promesses initiales de la Jamstack
• Ce que la Jamstack à réellement changé dans les architectures web
• Le mur de la réalité : le plafond de verre du statique
• Architecture Islands : la vraie rupture ?
• Au delà des Islands : la resumability
• La Jamstack a préparé le terrain du web composable
• L’héritage : ce qu’on en garde aujourd’hui
• Lexique

Aux origines: les promesses initiales

La définition historique de la JAMstack (avec des majuscules, à l’origine, pour l’acronyme), qui a été popularisée par Jamstack.org, reposait sur 3 piliers :

• JavaScript
• APIs
• Markup

L’idée sur laquelle repose cette architecture était simple, mais pas simpliste : pré-générer le HTML, distribuer les assets via un CDN (Content Delivery Network) et déléguer tout le reste à des APIs. Simple. Basique. 

La JAMstack apportait une nouvelle manière de penser le web, où le serveur n’était plus le centre du système. Là où AJAX permettait déjà de dynamiser des pages en utilisant des APIs, l’approche JAM allait plus loin en déplaçant le centre de gravité : le serveur n’était plus chargé de construire la page à la volée. A l’époque, c’était une petite révolution : le front devenait un artefact autonome, découplé du back, dans un monde dominé par des serveurs monolithiques, du rendu PHP et des applications ultra couplées. Ce concept totalement disruptif à profondément transformé les architectures frontend. 

Cette approche avait plusieurs points forts, notamment la sécurité (via la réduction de la surface d’attaque), les performances, une scalabilité infinie (avec un coût peu élevé) et une grande fiabilité de la disponibilité grâce au CDN.

A l’origine, la JAMstack, c’était donc ce genre d’implémentation :

Illustration : Alex Palma

Le front est généré au build par un “static site generator” (SSG). Le back est “headless”, c’est-à-dire qu’il fournit les données via une API. Lors du build par le SSG, ces données sont récupérées et intégrées dans les différentes pages. Le résultat est stocké sur un CDN. C’est la partie statique du site. L’utilisateur requête le CDN et reçoit le HTML statique.

La partie dynamique n’est pas toujours nécessaire, car la JAMstack à l’origine est venue avec le concept de Green IT et de frugalité, ce qui, nous allons le voir, a été un peu oublié dans la bataille. Mais si la partie dynamique existe, elle repose directement sur des APIs.

Dans sa forme originelle, cette architecture est simple et ultra efficace. Depuis, elle a perdu son acronyme et ses majuscules au fil de ses évolutions, qui l’ont un peu éloignée de ses valeurs originelles. Au-delà du buzzword, voyons quel a été son impact concret sur notre manière de concevoir le web.

Ce que la Jamstack a réellement changé dans les architectures web

On faisait du statique bien longtemps avant la Jamstack, en témoigne le tout premier site web créé au CERN sur l’ordinateur NeXT de Tim Berners-Lee, en 1989, que vous pouvez aller essayer dans un émulateur créé en 2019 pour célébrer les 30 ans du World Wide Web.

Illustration générée par IA

Ou encore le site du W3C en décembre 1996 (le CSS 1 a d’ailleurs vu le jour cette année-là, probablement créé par une belle âme pleine d’empathie pour les designers).

L’héritage principal de la Jamstack n’est donc pas vraiment le statique, mais plutôt le déplacement des responsabilités d’architecture. 

Avant, le serveur construisait la page, gérait le cache et contrôlait le cycle de rendu. Avec la Jamstack, le build devient une étape centrale, le CDN devient une brique structurante et le front devient distribuable de manière indépendante.

Cette évolution a accéléré des transformations majeures, et notamment la généralisation des APIs métier spécialisées (Payment/Search-as-a-service et autres SaaS), l’émergence des plateformes cloud-native pensées pour les architectures frontend distribuées, l’adoption massive des workflows Git-based, les concepts de Backend as a Service, et les CMS headless comme Strapi, Contentful, Payload et leurs homologues. Même WordPress s’est adapté en offrant un mode headless, et depuis quelques années, on peut même lui ajouter du GraphQL. Des outils comme Next, Nuxt ou encore Gatsby ont contribué à rendre cette approche mainstream. 

Mais en réalité, la Jamstack a surtout imposé une idée : le front est un système distribué. Et cette idée change tout. Contrairement à l’approche classique où le site vit sur un serveur central, il est désormais éclaté et répliqué sur un CDN pour être servi au plus proche de l’utilisateur. C’est un premier pas vers les concepts de frugalité numérique, car en réduisant la distance physique entre la donnée et le consommateur de celle-ci, on réduit mécaniquement l’impact du transport de cette donnée.

Si ce modèle de découplage a remporté un franc succès, il s’est en réalité assez vite heurté à un plafond de verre technique.

Le mur de la réalité : le plafond de verre du statique

Illustration générée par IA

Le full static fonctionne très bien dans certains cas précis, mais pas dans tous les contextes. Assez rapidement, plusieurs limites structurelles ont émergé.

Explosion des temps de build… et du poids des artefacts

Pré-générer quelques dizaines de pages est relativement simple, et le build devrait être un détail technique. Mais pré-générer un très grand nombre de pages, des catalogues e-commerce de plusieurs milliers d’articles, des variantes localisées… Tout ça peut rendre le build extrêmement long, et en faire un vrai sujet d’architecture.

Avec mon équipe, sur de simples sites vitrines statiques en Astro, nous atteignons déjà les 10 minutes de temps de build. Je n’ose imaginer le temps nécessaire pour builder un site e-commerce avec 10 000 articles. Et ce build devra être relancé à chaque nouveau contenu statique mis en ligne. On comprend aisément que cette méthode n’est pas adaptée à tous les contextes.

La taille de l’artefact de build peut aussi vite devenir conséquente. Dans notre cas, il contient la totalité des contenus : articles, projets, images optimisées, et de très nombreux PDF. Dans le cadre d’un SI très réglementé, nous atteignons parfois les limites de taille autorisées pour les images Docker. Il faut également prendre en compte que le site va vivre et être alimenté, et qu’il va falloir anticiper l’augmentation progressive de sa taille.

Cela reste une approche très pertinente dans notre contexte spécifique. Mais je ne choisirais pas forcément de l’appliquer dans un autre contexte.

Cohérence des builds statiques

Cela peut également poser des problèmes de cohérence. Si un build dure 30 minutes et qu’un nouveau contenu est publié entre temps, l’artefact généré peut déjà être obsolète au moment de son déploiement.

Invalidations de cache complexes

Et en effet, plus le contenu change fréquemment, moins le modèle “build then deploy” est susceptible de répondre aux besoins réels. Pour contourner cette rigidité, on a vu apparaître des stratégies de revalidation, d’ISR (Incremental Static Regeneration), de cache invalidation, d’edge recomputation. Ces stratégies ont eu pour effet de transformer le paradigme de base de la Jamstack : on réintroduit progressivement du calcul serveur, pour répondre aux limites du full static.

Le cache devient alors multicouche (CDN, serveur, client…), ce qui amène une nouvelle problématique : les différentes couches n’ont pas forcément la même version au même moment. Il ne suffit donc plus de savoir quand invalider, mais il faut aussi garantir la cohérence globale du cache distribué. 

La complexité ne disparaît pas, elle se déplace

A l’origine, la Jamstack visait moins d’infrastructure, moins de serveurs, moins d’opérations. En pratique, dans de nombreux cas, la complexité a simplement migré : 

• vers le build
• vers la CI/CD
• vers les stratégies de cache
• vers les APIs distribuées
• vers l’orchestration front/back…

Là où on nous promettait simplicité et sécurité, on se retrouve avec une architecture distribuée qui implique de plus en plus de complexité. Et force est de constater que le gain de performance ou de scalabilité ne compense pas toujours cette charge cognitive supplémentaire.

Le véritable use case est niche

Le modèle Jamstack fonctionne remarquablement bien pour des sites vitrines, du contenu éditorial, des pages marketing ou de la documentation. Mais dès qu’une application introduit de la recherche dynamique, des dashboards, des données utilisateur évolutives ou personnalisées, le paradigme montre rapidement ses limites et l’architecture se complexifie considérablement.

Là où la promesse initiale était de se passer du serveur applicatif, en pratique, les besoins métier réel réintroduisent progressivement de la logique d’exécution dynamique dans un modèle initialement statique (authentification, permissions, contenu contextualisé), accélérant de fait l’adoption de l’ISR, du SSR (server-side rendering) et des edge functions.

De même, l’idée que servir le front depuis un CDN assurait des performances optimales était une illusion. En pratique, un certain nombre d’applications Jamstack sont devenues des SPA massivement hydratées avec plusieurs centaines de ko de JavaScript pour rendre… des pages statiques. Le coût est toujours là, il a simplement été déplacé du serveur vers le client.

Ce qu’on doit en retenir, c’est que la Jamstack est un (très bon) paradigme de niche, mais qu’elle n’est pas adaptée à tous les contextes. Face à ces limites, une nouvelle approche a émergé pour réconcilier le statique et le dynamique : les “islands”.

Islands architecture : la vraie rupture ?

C’est dans ce contexte qu’on voit arriver dès 2019 les architectures dites “Islands”. Nommé ainsi en 2020 par le créateur de Preact, Jason Miller, dans son article “Islands Architecture” qui reste une référence sur le sujet, le concept de petites “poches d’interactivité” a été initialement introduit par Katie Sylor-Miller, architecte front chez Etsy. 

Il est à la base du meta-framework Astro, créé par Fred K. Schott en 2021, qui a popularisé l’approche “static-first” et a industrialisé l’architecture Islands. Au plus proche des standards du web, Astro supporte les frameworks front majeurs (React, Vue, Preact, Svelte et Solid). Leur mojo : “Zero JavaScript by default”. Par défaut, Astro génère du statique, et si vous voulez de l’interactivité, il faudra l’ajouter via des îlots. Concrètement, votre composant devient dynamique, et le reste de votre page demeure statique. On hydrate donc uniquement ce dont on a réellement besoin. 

Illustration générée par IA

C’est aussi le paradigme à la base du langage Marko, qui étend le HTML pour lui ajouter de la réactivité de manière déclarative, ou encore de Fresh, un framework full stack Deno-native qui fournit des Islands légères, basées sur Preact et Signals (et qui promet “no node_modules”, avis aux amateurices).

L’idée est simple, et brillante : générer le HTML coté serveur (au build ou à la requête), livrer du HTML statique et hydrater uniquement les composants interactifs, s’il y en a. Si le changement paraît subtil, il est en réalité majeur. Ces dernières années, avec l’avènement des SPA, les frameworks ont considéré la page HTML comme une simple étape transitoire avant l’exécution du JS. 

Les architectures Islands inversent cette logique : le HTML redevient la base du document. Le paradigme bascule du JS-first au HTML-first.

Au-delà des Islands : la resumability

Certains poussent encore plus loin cette réflexion, comme le framework Qwik, encore relativement exotique mais très intéressant par son approche : l’objectif est d’avoir des applications réactives instantanément, y compris sur mobile. On ne cherche plus seulement à réduire le JavaScript, mais à télécharger et exécuter uniquement le strict minimum de l’application.

Pour cela, Qwik introduit le concept de resumability, qui permet aux applications de continuer leur exécution là où le serveur l’avait laissée en gardant une trace de l’état de l’application, contrairement aux autres frameworks qui perdent cette trace lors du passage du serveur au client. 

Les structures de données des autres frameworks doivent donc être reconstruites dans le navigateur, dupliquant ainsi le travail qui a déjà été effectué sur le serveur. Le fait de reconstruire ces structures de données et d’attacher les listeners, c’est ce qu’on appelle communément “l’hydratation”. Qwik sérialise le graphe de composants, les associations d’événements, et l’état de l’application dans le HTML lors du passage du serveur au client, ce qui permet au client de reprendre l’exécution exactement là où le serveur s’est arrêté, réduisant drastiquement le coût de l’hydratation telle qu’on la connaît dans les SPA classiques.

Qwik pousse donc à l’extrême l’idée initiée par les architectures Islands : le JavaScript ne doit plus être chargé à l’échelle de l’application, mais uniquement au moment exact où l’utilisateur en a besoin. Couplé à une taille de bundle la plus réduite possible (l’autre point fort de Qwik !), ce modèle vise à obtenir des applications avec quasiment aucun JavaScript initial, et où le téléchargement du JavaScript se fait progressivement, au gré des interactions de l’utilisateur.

La Jamstack a préparé le terrain du web composable

Les frameworks actuels ont progressivement absorbé les idées de la Jamstack pour construire des architectures hybrides, capables de choisir dynamiquement le bon mode de rendu selon le contexte. Si le terme ‘Jamstack” est en voie de disparition, ses principes, eux, sont donc partout.

Aujourd’hui, la grande majorité du web n’est plus ni entièrement statique, ni entièrement dynamique, et dans une même application, on peut retrouver des pages pré-générées, du rendu serveur, du streaming, du cache edge, des composants interactifs hydratés à la demande… Cette hybridation est directement héritée des contraintes rencontrées par les premières architectures Jamstack.

Et dans la communauté Jamstack, on parle désormais de Composable Web : il n’y a plus un backend, mais plusieurs APIs, des headless CMS, des microservices à orchestrer. Il n’y a plus un seul frontend, mais un site web, une app mobile, une app desktop et peut-être même une application embarquée sur micro-contrôleur dans un quelconque objet connecté.

Voyons comment la Jamstack a ouvert la voie au web composable.

Illustration : Alex Palma

Backend-for-frontend (BFF) et architectures multi-runtime

La multiplication des APIs et des services distribués a fait émerger un nouveau besoin : adapter les données spécifiquement aux contraintes du front, et éviter de coupler directement chaque frontend à l’ensemble des APIs métier. 

C’est précisément le rôle du pattern Backend-for-frontend, qui repose sur une séparation claire des responsabilités. Le BFF agit comme une couche d’orchestration entre les différents frontends (app mobile, web, desktop, embarqué…) et la partie back “composable” d’un projet (microservices, APIs…). Son objectif est de fournir un point d’entrée dédié pour chaque type de frontend, et de limiter le couplage avec les différentes APIs métier.

Et il n’y a qu’un pas pour basculer vers des architectures MACH (Microservices, API-first, Cloud-native, Headless), qui prolongent plusieurs principes popularisés par la Jamstack, au prix d’une complexité d’infrastructure bien plus importante que ne le laissaient imaginer les promesses initiales du “static-first”.

Edge functions : rapprocher le calcul de l’utilisateur

La Jamstack avait déjà déplacé les assets au plus proche des utilisateurs avec des CDN. Les edge functions complètent cette approche : elles ne distribuent plus seulement du contenu, elles exportent la logique applicative elle-même sur le réseau edge. Le CDN ne sert donc plus seulement à stocker, il devient un environnement d’exécution distribué. Le modèle “static-first” évolue alors vers du “cache-first, compute-when-needed” (et pas loin, s’il te plait).

Streaming SSR : le flux de rendu

Le SSR classique a une limite fréquente : tant que la page n’est pas prête, il n’envoie rien au client. Le streaming SSR permet de contourner cette contrainte en envoyant progressivement le HTML au navigateur, au fur et à mesure qu’il devient disponible. Il est désormais utilisé dans de nombreux frameworks, à l’image de React, Next, Nuxt… Marko l’utilise également. Avec cette approche, le rendu n’est plus un événement unique, mais un flux.

Hybrid rendering

Si certaines pages gagnent à être statiques, d’autres nécessitent du SSR, de la personnalisation, du temps réel ou des données fraîches (très) régulièrement. Aujourd’hui, il est courant de combiner ces stratégies à l’échelle d’une route, d’un composant ou d’un fragment de page, comme on l’a vu avec les architectures hybrides telles que les Islands. Le rendu devient un choix d’architecture contextuel, plutôt qu’une décision globale commune à toute l’application.

L’héritage: ce qu’on en garde aujourd’hui

Vous l’aurez compris, le retour à la simplicité proné par la Jamstack dans sa première mouture est loin derrière nous et a progressivement évolué vers quelque chose de beaucoup plus complexe, très éloigné de l’idée originelle. On est partis d’une séparation front/back, pour passer à une séparation du rendu, puis du calcul, puis des runtimes…

Et si certains affirment que la Jamstack est morte là où d’autres pensent qu’elle est devenue mainstream, c’est probablement parce que ces évolutions ne cochent plus du tout les cases des promesses initiales. Une certaine partie de la communauté considère donc que ce n’est plus “jam”, et les puristes restent fermement attachés aux principes d’origine, qui répondent toujours aussi bien à certains besoins très spécifiques.

Illustration : Alex Palma

De mon point de vue (de puriste, je l’admets), embarquer par défaut des choses dont on n’a pas besoin, ce n’est pas une approche Jamstack. Et si le mot a été absorbé par les évolutions qu’il a inspirées et dont il a été à l’origine, il n’en reste pas moins un concept nécessaire aujourd’hui plus que jamais, un appel à la simplicité et à des applications plus responsables, qui pousse à se poser les bonnes questions : 

• Ai-je vraiment besoin de JavaScript ?
• Ai-je vraiment besoin de cette feature ?
• Ai-je vraiment besoin de ces 32 APIs et de ces micro-services ?  
• Est-ce que je joue le jeu des services cloud pour héberger très chèrement une app statique sous laquelle j’ai mis plein de serverless inutile ?
• Est-ce que la complexité de mon infra est réellement justifiée par un ROI mesurable ?
• En somme : quel est mon besoin réel, et comment y répondre en appliquant le principe KISS (Keep It Stupid Simple) ?

Dans sa version originelle, la Jamstack incite à une approche minimaliste et optimisée du web. Une approche qui me semble cohérente avec les préoccupations portées par le Green IT, et qui reste tout à fait pertinente aujourd’hui, dans certains contextes. Il n’appartient qu’à nous, développeuses et développeurs, de faire passer le véritable besoin avant la hype.

Et si certains voient aujourd’hui la Jamstack comme une transition entre le web “server-centric” et le web distribué “edge-centric”, je la vois surtout comme une approche de frugalité essentielle : faire moins et le faire mieux, à partir des outils hybrides hérités de ses concepts.

Paradoxalement, cette hybridation valide une grande partie des intuitions initiales de la Jamstack :

• distribuer au plus proche de l’utilisateur,
• limiter le travail serveur,
• optimiser le coût du rendu,
• découpler les responsabilités.

Pour conclure, même si le terme s’efface progressivement, son héritage structure encore une grande partie des architectures frontend actuelles. Aujourd’hui, la Jamstack est devenue un spectre de solutions entre l’approche full-statique et le web composable, dont on espère qu’il continuera d’inspirer un web plus frugal et raisonné.

Lexique

Hydratation

Processus par lequel le JS vient “donner vie” au HTML en reconstruisant l’état et en attachant les évènements dans le navigateur, ce qui permet de rendre la page ou le composant interactif.

SSG (Static Site Generator)

Stratégie de rendu qui génère les pages HTML en amont, au moment du build, pour les servir telles quelles (statiques) à l’utilisateur.

SSR (Server Side Rendering)

Génération du HTML à la volée, sur le serveur, à chaque fois qu’un utilisateur demande une page.

Island Architecture

Concept architectural consistant à livrer une page HTML majoritairement statique, avec des îlots d’interactivité hydratés de manière indépendante.

CDN (Content Delivery Network)

Réseau de serveurs distribués géographiquement dont le rôle est de mettre en cache et servir des contenus (HTML, images, CSS…) au plus proche des utilisateurs pour accélérer le chargement. Il peut également exécuter de la logique en périphérie via des edge functions.

Edge Functions

Exécution de code (logique métier) sur des serveurs distribués géographiquement. Il s’agit globalement d’une forme de serverless allégé (runtime minimal), exécuté sur les nœuds du CDN les plus proches de l’utilisateur afin de réduire au maximum la latence.

Edge recomputation

Stratégie qui consiste à régénérer une ressource ciblée au plus proche de l’utilisateur via des edge functions, afin de réduire la latence et d’éviter la régénération centralisée.

SaaS (Software as a Service)

Applications hébergées par un fournisseur et accessibles via des APIs.

ISR (Incremental Static Regeneration)

Stratégie de rendu qui consiste à régénérer une page statique après le build, sans reconstruire tout le site. En pratique, on configure une durée de revalidation. Lorsque cette dernière expire, la page est régénérée et le cache est mis à jour avec cette nouvelle version. 

CMS (Content Management System)

Système de gestion de contenu. On distingue notamment les CMS :

• monolithiques, qui fournissent le rendu et le back-office (WordPress natif, Joomla…)
• headless, qui fournissent un back-office et une API, le front n’est pas inclus (Contentful, Strapi, Payload…)