Jamstack

Jamstack est une approche de construction de sites web dans laquelle les pages sont générées à l'avance et servies depuis un réseau de diffusion de contenu, les fonctions dynamiques étant assurées par des API et du JavaScript côté navigateur. Le nom vient de JavaScript, API et Markup.

Le contraste avec un site dynamique classique est net. Sur une installation traditionnelle, chaque visite déclenche l'exécution de code et des requêtes en base pour reconstruire la page à la volée. En Jamstack, la page est déjà imprimée et distribuée dans des points de présence proches du visiteur : le serveur n'a plus qu'à la remettre.

Comment ça marche

Le contenu vit dans un CMS découplé — Strapi, Directus, Contentful — ou dans des fichiers Markdown versionnés avec le code. Un générateur comme Nuxt, Next.js, Astro, Hugo ou Eleventy construit l'ensemble des pages HTML au moment de la compilation. Le résultat est déployé sur une plateforme de diffusion telle que Netlify, Vercel ou Cloudflare Pages.

Ce qui reste réellement dynamique — formulaire, recherche, panier, espace membre — est confié à des API et à des fonctions exécutées à la demande. La frontière s'est d'ailleurs brouillée : la régénération incrémentale, le rendu serveur à la demande et l'exécution en périphérie permettent aujourd'hui de mélanger pages figées et pages calculées dans un même projet.

À quoi ça sert concrètement

• Sites éditoriaux, blogs, documentations, sites vitrines et pages d'atterrissage
• Performance et référencement : le temps de réponse initial devient très faible, ce qui aide sur les Core Web Vitals
• Sécurité : pas de base de données exposée, pas d'interface d'administration publique sur le domaine
• Coûts maîtrisés et pics de trafic absorbés par le réseau de diffusion
• Déploiements atomiques avec retour arrière immédiat en cas de problème

Les pièges

Le temps de compilation est le premier. Quelques centaines de pages se génèrent en une minute ; plusieurs dizaines de milliers peuvent demander une heure, ce qui rend chaque correction de coquille pénible. Les stratégies de génération incrémentale existent mais doivent être prévues dès la conception.

Le second concerne les données réellement temps réel — stock, disponibilité, prix négocié — mal servies par une page figée : il faut alors les recharger côté client ou déclencher une revalidation. Le troisième est humain : les rédacteurs ne voient plus leur modification immédiatement, il faut donc leur fournir une prévisualisation. Ajoutez enfin la dépendance à plusieurs prestataires, chacun avec ses quotas et sa facture.

Quand le choisir, quand l'éviter

L'approche est excellente pour un contenu qui change quelques fois par jour et pour lequel la vitesse et le référencement comptent. Elle convient mal aux applications transactionnelles — intranet, ERP, marketplace avec stock vivant — où un rendu serveur mis en cache reste plus simple.