J'ai construit pour le web assez longtemps pour me souvenir quand "Jamstack" n'était que une présentation de conférence donnée par Mathias à Smashing Conf. Maintenant ? Nike, Spotify, et Twilio font fonctionner des portions de leur présence web de cette façon.

Voici ce que vous devez savoir : Jamstack n'est pas un framework. C'est une approche architecturale qui change la façon dont vous construisez, déployez, et servez des sites web. Et elle a bien mûri au-delà de la phase "juste pour les blogs".

Ce guide fonctionne pour les deux côtés de la table. Ingénieurs : nous allons approfondir l'invalidation ISR, les patterns de fonctions edge, les configurations de build réelles. Responsables marketing et produit : nous allons montrer pourquoi cela se traduit par des pages plus rapides, de meilleurs classements SEO, moins de pannes à 3 heures du matin.

Table des matières

L'idée centrale : ce que Jamstack signifie réellement

Le nom signifiait JavaScript, APIs, et Markup. Mathias Biilmann (co-fondateur de Netlify) l'a inventé vers 2015-2016 parce qu'il n'y avait pas de bon raccourci pour le pattern que son équipe voyait constamment. Le "JAM" en majuscules a été assoupli en "Jamstack" -- et honnêtement, l'acronyme importe moins que deux principes fondamentaux :

  1. Pré-rendu -- Générer autant que possible de votre site en avance, pas à chaque requête.
  2. Découplage -- Séparer votre frontend des services backend, des bases de données, et de la gestion de contenu.

C'est tout. Tout le reste découle de ces deux idées.

Pourquoi les responsables marketing devraient s'en préoccuper

Vitesse. Disponibilité. SEO.

Les Core Web Vitals de Google influencent directement les classements de recherche. Les pages pré-rendues servies depuis un CDN surpassent constamment les pages rendues côté serveur sur les métriques LCP (Largest Contentful Paint) et FID (First Input Delay). Une étude 2025 du Chrome UX Report de Google a montré que les sites utilisant des architectures axées sur le statique réussissaient les seuils des Core Web Vitals à près de deux fois le taux des sites rendus traditionnellement côté serveur.

Traduction : pages plus rapides → meilleurs classements → plus de trafic.

Pourquoi les ingénieurs devraient s'en préoccuper

Réduction de la complexité opérationnelle. Pas de serveurs d'origine à corriger à 2 heures du matin. Pas de pools de connexions de base de données à affiner. Votre surface d'attaque rétrécit dramatiquement quand vous servez des actifs statiques depuis un CDN avec les appels API gérés par des services gérés.

Vous livrez plus vite parce que votre pipeline CI/CD est un git push qui déclenche une compilation et se déploie globalement en minutes.

Pré-rendu : construire une fois, servir partout

Le pré-rendu est la fondation. Au lieu qu'un serveur génère du HTML à chaque requête (le modèle WordPress/PHP), un site Jamstack génère toutes ses pages HTML pendant une étape de construction avant le déploiement.

Modèle mental simplifié :

Traditionnel : Requête utilisateur → Serveur → Requête base de données → Rendu du template → HTML → Utilisateur
Jamstack :    Étape de construction → HTML/CSS/JS statique → CDN → Requête utilisateur → Réponse instantanée

L'étape de construction s'exécute dans CI/CD (Vercel, Netlify, GitHub Actions, peu importe). Elle extrait le contenu de votre CMS via API, l'exécute à travers le processus de construction de votre framework, et produit un dossier de fichiers statiques. Ces fichiers sont poussés vers un CDN.

Génération de site statique (SSG)

L'approche Jamstack originale. Chaque page est générée à la compilation. Les frameworks qui gèrent bien cela :

  • Astro -- Livre zéro JavaScript par défaut. Excellent pour les sites riches en contenu. Nous l'utilisons beaucoup pour les sites marketing chez Social Animal (voir notre travail Astro).
  • Next.js -- Supporte SSG via getStaticProps et getStaticPaths, plus des modes de rendu hybride.
  • Hugo -- Des compilations extrêmement rapides en Go. Un site de 10 000 pages se construit en secondes.
  • Eleventy (11ty) -- Minimal, flexible, pas de verrouillage de framework.

Voici SSG en Next.js :

// pages/blog/[slug].js
export async function getStaticPaths() {
  const posts = await fetchAllPostSlugs(); // depuis CMS sans tête
  return {
    paths: posts.map((slug) => ({ params: { slug } })),
    fallback: 'blocking', // repli ISR -- plus d'infos plus tard
  };
}

export async function getStaticProps({ params }) {
  const post = await fetchPostBySlug(params.slug);
  return {
    props: { post },
    revalidate: 60, // ISR : régénérer toutes les 60 secondes
  };
}

Approche comparable en Astro :

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
---
<article>
  <h1>{post.data.title}</h1>
  <Content />
</article>

Le problème du temps de construction

SSG a une limitation bien connue : les temps de construction augmentent avec le nombre de pages. Un catalogue e-commerce de 50 000 pages peut prendre plus de 30 minutes à construire. C'était une vraie douleur en 2020-2022.

La réponse de l'industrie ? ISR et les constructeurs à la demande (plus sur cela dans la section ISR).

Distribution CDN : pourquoi la géographie compte

Un CDN met en cache vos fichiers statiques sur des nœuds edge dans le monde. Quand un utilisateur à Tokyo demande votre page, il l'obtient depuis un nœud edge de Tokyo -- pas depuis votre serveur d'origine en Virginie.

La différence de performance est dramatique. Une page rendue côté serveur typique pourrait avoir un TTFB (Time to First Byte) de 200-800ms selon la charge du serveur et la distance utilisateur. Une page servie par CDN statique ? Généralement 10-50ms.

Fournisseurs CDN pour Jamstack

Fournisseur Niveau gratuit Emplacements edge Caractéristiques notables
Vercel 100GB bande passante/mois 110+ Conçu pour Next.js, mise en cache edge automatique
Netlify 100GB bande passante/mois 150+ Prévisualisations de déploiement, gestion de formulaires, identité
Cloudflare Pages Bande passante illimitée 330+ Intégration Workers, zéro démarrages froids
AWS CloudFront 1TB/mois (12 mois) 450+ Contrôle de cache granulaire, Lambda@Edge
Fastly Usage-based 80+ Purge instantanée, logique edge basée sur VCL

Pour la plupart des projets Jamstack en 2026, Vercel et Netlify gèrent le déploiement et le CDN en un seul package. Vous poussez du code, ils construisent et distribuent. Si vous avez besoin de plus de contrôle sur les règles de mise en cache ou si vous fonctionnez à très grande échelle, Cloudflare ou Fastly vous donnent cette granularité.

Invalidation du cache

La partie difficile n'est pas de servir du contenu en cache -- c'est de savoir quand purger ce cache. Quand un éditeur de contenu publie un nouvel article de blog, à quelle vitesse cela se met-il en ligne ?

Avec SSG pur, vous déclenchez une compilation complète. Avec ISR, vous invalidez des chemins spécifiques. Avec les fonctions edge, vous pouvez le faire par requête. Chaque approche a des compromis entre la fraîcheur et la complexité de construction.

Découplage des API : le backend devient un service

Dans une configuration WordPress ou Drupal traditionnelle, le CMS est le serveur. Il stocke le contenu, rend les templates, gère l'authentification, traite les formulaires, et sert les pages. Si le CMS tombe en panne, tout tombe en panne.

Jamstack découple tout cela. Votre frontend est juste des fichiers sur un CDN. Votre backend est une collection d'APIs -- chacune gérant une préoccupation :

  • Contenu → API CMS sans tête (Sanity, Contentful, Storyblok)
  • Authentification → Auth0, Clerk, Supabase Auth
  • Paiements → API Stripe
  • Recherche → Algolia, Meilisearch, Typesense
  • Formulaires → Formspree, Netlify Forms, Basin
  • E-commerce → API Shopify Storefront, Saleor, Medusa

C'est souvent appelé une "architecture composable". Vous choisissez les meilleurs services de sa catégorie pour chaque fonction plutôt que d'accepter ce que votre CMS monolithique regroupe.

Le compromis d'ingénierie

Je ne prétendrai pas que c'est tout avantage. Le découplage introduit de la complexité d'intégration. Vous gérez maintenant les clés API, les configurations de webhook, et les flux de données entre plusieurs services. Un monolithe est plus facile à comprendre.

Le compromis en vaut la peine quand vous avez besoin de performance à l'échelle, quand différentes équipes doivent travailler indépendamment, ou quand vous voulez remplacer des services sans réécrire votre site entier.

Chez Social Animal, nous aidons les équipes à réfléchir exactement à ce type de décision architecturale. Notre travail de développement CMS sans tête est spécifiquement construit autour de trouver la bonne composition de services pour chaque projet.

CMS sans tête : du contenu sans le monolithe

Un CMS sans tête stocke et gère le contenu mais n'a pas d'opinion sur comment il est affiché. Au lieu de rendre les pages (comme WordPress le fait), il expose le contenu via une API. Votre frontend consomme cette API au moment de la construction, au moment de la requête, ou les deux.

Comparaison des CMS sans tête (2026)

CMS Type Style API Niveau gratuit Meilleur pour
Sanity Basé sur API GROQ + GraphQL Généreux (gratuit jusqu'à 200K requêtes API/mois) Modélisation de contenu flexible, collaboration en temps réel
Contentful Basé sur API REST + GraphQL Plan communautaire (5 utilisateurs) Équipes d'entreprise, localisation
Storyblok Basé sur API REST + GraphQL Plan communautaire (1 utilisateur) Édition visuelle, contenu orienté composants
Strapi Auto-hébergé / Cloud REST + GraphQL Gratuit (auto-hébergé) Contrôle total, backends personnalisés
Payload CMS Auto-hébergé REST + GraphQL Gratuit (open source) TypeScript natif, configuration centrée sur le code
WordPress (sans tête) Auto-hébergé REST + WPGraphQL Gratuit (open source) Équipes avec expertise WordPress existante
Keystatic Basé sur Git Système de fichiers Gratuit (open source) Sites lourds en markdown, contenu dirigé par les développeurs

Le choix dépend de votre équipe. Si vos éditeurs ont besoin d'une expérience d'édition visuelle soignée, Storyblok ou le Studio de Sanity sont difficiles à battre. Si vous voulez que le contenu soit stocké dans votre référentiel Git sous forme de fichiers markdown, Keystatic ou même les collections de contenu intégrées d'Astro fonctionnent bien.

Comment le contenu circule dans Jamstack

1. L'éditeur publie le contenu dans le CMS sans tête
2. Le CMS envoie un webhook à la plateforme de construction (Vercel/Netlify)
3. La plateforme de construction déclenche une nouvelle construction ou une revalidation ISR
4. Le framework récupère le dernier contenu via l'API du CMS
5. Les pages statiques sont générées et déployées sur le CDN
6. L'utilisateur voit le contenu mis à jour (secondes à minutes, selon la stratégie)

Pour les sites marketing riches en contenu, ce flux de travail est transformateur. Les éditeurs obtiennent une interface de contenu dédiée. Les développeurs obtiennent un contrôle total du frontend. Ni l'un ni l'autre ne bloque l'autre.

Nous voyons ce pattern constamment dans nos projets Next.js.

Fonctions edge : le calcul à la couche CDN

Les fonctions edge sont la plus grande évolution du Jamstack depuis ISR. Elles vous permettent d'exécuter de petits morceaux de code côté serveur aux nœuds edge du CDN -- près de l'utilisateur, avec des temps de démarrage à froid mesurés en millisecondes à un chiffre.

Pensez à elles comme des fonctions serverless légères qui s'exécutent avant que la réponse n'atteigne l'utilisateur. Elles sont parfaites pour :

  • Tests A/B -- Acheminer les utilisateurs vers différentes variantes de page sans scintillement côté client
  • Personnalisation -- Servir du contenu différent basé sur la géolocalisation, les cookies, ou les en-têtes
  • Vérifications d'authentification -- Vérifier les tokens JWT avant de servir le contenu protégé
  • Réécriture d'URL et redirections -- Gérer la logique de routage complexe au edge
  • Feature flags -- Basculer les fonctionnalités sans redéployer

Exemple de fonction edge (Vercel)

// middleware.ts (s'exécute au edge sur chaque requête)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const country = request.geo?.country || 'US';
  
  // Rediriger les utilisateurs de l'UE vers la version conforme au RGPD
  if (['DE', 'FR', 'IT', 'ES', 'NL'].includes(country)) {
    return NextResponse.rewrite(new URL(`/eu${request.nextUrl.pathname}`, request.url));
  }
  
  // Test A/B : division 50/50 basée sur un cookie
  const bucket = request.cookies.get('ab-bucket')?.value;
  if (!bucket) {
    const response = NextResponse.next();
    response.cookies.set('ab-bucket', Math.random() > 0.5 ? 'a' : 'b');
    return response;
  }
  
  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!api|_next/static|favicon.ico).*)'],
};

Fournisseurs de fonctions edge

  • Vercel Edge Middleware -- S'exécute avant chaque route, intégration Next.js étroite
  • Netlify Edge Functions -- Basé sur Deno, s'exécute sur le réseau de Deno Deploy
  • Cloudflare Workers -- Réseau edge le plus grand, isolates V8, pas de démarrages froids
  • Deno Deploy -- Déploiement global sans configuration, construit sur le runtime Deno

Les fonctions edge brouillent la ligne entre statique et dynamique. Vous obtenez les avantages de latence de la livraison CDN avec juste assez de logique côté serveur pour gérer la personnalisation.

C'est là que Jamstack en 2026 brille vraiment -- ce n'est plus "juste des sites statiques".

ISR : le meilleur du statique et du dynamique

Nous avons frappé ce problème très fort en 2020. Le client avait un catalogue e-commerce de 50 000 pages. Les compilations complètes prenaient plus de 30 minutes. Les éditeurs de contenu publiaient des mises à jour et attendaient. Et attendaient.

La régénération statique incrémentale (ISR) l'a résolu. Next.js l'a introduite en 2020. Les pages sont générées statiquement au moment de la construction mais peuvent être régénérées en arrière-plan après un intervalle de temps spécifié ou à la demande via les appels API.

Comment fonctionne ISR

  1. La première requête frappe le CDN et sert la page statique en cache
  2. Si la page est plus ancienne que l'intervalle revalidate, Next.js déclenche une régénération en arrière-plan
  3. La requête suivante obtient la page nouvellement générée
  4. Les utilisateurs ne voient jamais d'état de chargement -- ils obtiennent toujours une version en cache
// ISR Next.js avec revalidation à la demande
// pages/api/revalidate.js
export default async function handler(req, res) {
  // Vérifier le secret du webhook du CMS
  if (req.query.secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: 'Token invalide' });
  }

  try {
    const { slug } = req.body;
    await res.revalidate(`/blog/${slug}`);
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).send('Erreur de revalidation');
  }
}

Cela signifie qu'un éditeur de contenu publie une modification dans Sanity, un webhook déclenche votre endpoint de revalidation, et seule cette page spécifique est régénérée. Le reste de votre site de 50 000 pages reste inchangé.

Les temps de construction passent de 30 minutes à des millisecondes pour les mises à jour de contenu.

ISR vs SSG vs SSR

Stratégie Quand le HTML est généré Fraîcheur Performance Meilleur pour
SSG Temps de construction uniquement Obsolète jusqu'à la prochaine compilation Plus rapide (CDN pur) Sites avec modifications peu fréquentes
ISR Temps de construction + régénération en arrière-plan Secondes à minutes obsolète Rapide (CDN avec mises à jour en arrière-plan) Sites de contenu avec mises à jour régulières
SSR Chaque requête Toujours frais Plus lent (dépendance au serveur) Pages hautement dynamiques, personnalisées
SSR edge Chaque requête au edge Toujours frais Rapide (calcul edge) Dynamique + faible latence

En pratique, la plupart des sites Jamstack en production en 2026 utilisent une approche hybride. Les pages marketing sont SSG. Les articles de blog utilisent ISR avec revalidation de 60 secondes. Les pages de tableau de bord utilisent SSR ou le rendu côté client.

Next.js et Astro supportent tous deux ce type de stratégie de rendu par route.

Jamstack vs architecture traditionnelle

Aspect Traditionnel (WordPress/Drupal) Jamstack
Rendu Côté serveur, par requête Pré-rendu + CDN en cache
Hébergement Nécessite un serveur web + base de données Fichiers statiques sur CDN
Mise à l'échelle Verticale (serveur plus grand) ou couches de cache Horizontale par défaut (le CDN la gère)
Sécurité Grande surface d'attaque (serveur, BD, plugins) Minimale (fichiers statiques, clés API côté serveur)
TTFB 200-800ms typique 10-50ms typique
Édition de contenu Interface CMS intégrée CMS sans tête séparé
Déploiement FTP/SSH, redémarrages serveur Git push → construction + déploiement automatique
Coût à l'échelle Augmente avec le trafic (ressources serveur) Souvent plat ou minimal (bande passante CDN)
Expérience développeur Liée au langage de template du CMS N'importe quel framework frontend

Je veux être honnête ici : l'architecture traditionnelle n'est pas mauvaise. WordPress alimente plus de 40% du web pour de bonnes raisons -- c'est mature, bien compris, et a un énorme écosystème.

L'approche Jamstack gagne quand la performance est critique, quand vous avez besoin de vous adapter à des pics imprévisibles, ou quand votre équipe de développement veut travailler avec des outils frontend modernes.

Exemples réels de production

Laissez-moi partager quelques exemples concrets -- pas des scénarios hypothétiques, mais des architectures réelles en production.

Exemple 1 : Catalogue de produits e-commerce

Stack : Next.js + API Storefront Shopify + Sanity (pour le contenu éditorial) + Vercel

Une marque DTC fashion avec laquelle nous avons travaillé avait ~8 000 pages de produit. En utilisant ISR avec revalidation de 5 minutes, les pages de produit restaient fraîches sans compilations complètes. Le contenu éditorial (lookbooks, guides de style) vivait dans Sanity. Shopify gérait l'inventaire et le paiement.

Le résultat : le TTFB moyen a diminué de 680ms à 35ms après la migration de leur thème Shopify Liquid.

Exemple 2 : Site marketing multi-marques

Stack : Astro + Storyblok + Cloudflare Pages

Une entreprise SaaS exécutant quatre marques de produit sous un domaine. Chaque marque avait un design visuel différent mais partageait la navigation et les composants de pied de page. L'architecture island d'Astro signifiait que la plupart des pages étaient livrées avec zéro JavaScript côté client. L'éditeur visuel de Storyblok permettait à l'équipe marketing de réorganiser les sections de page sans intervention du développeur.

Temps de construction pour l'ensemble du site de 400 pages : ~45 secondes.

Exemple 3 : Portail de documentation

Stack : Next.js App Router + contenu MDX dans Git + Recherche Algolia + Vercel

Une entreprise d'outils pour développeurs avec 2 000+ pages de documentation. Le contenu vivait sous forme de fichiers MDX dans le référentiel -- pas besoin de CMS externe. Algolia indexait le contenu au moment de la construction pour une recherche instantanée. ISR gérait les quelques pages dynamiques (changelog, statut).

L'équipe utilisait les déploiements de prévisualisation de Vercel pour que les rédacteurs techniques puissent examiner les modifications de documentation avant la fusion.

Exemple 4 : Site de nouvelles/médias

Stack : Next.js + Contentful + Fastly CDN + AWS Lambda

Un éditeur de médias numérique avait besoin de charges de page infraseconde pour le SEO et l'optimisation des revenus publicitaires. Les pages d'actualités dernière minute utilisaient ISR à la demande déclenché par les webhooks Contentful -- les nouveaux articles se mettaient en ligne en moins de 10 secondes après la publication. Les fonctions edge gérait l'insertion d'annonces ciblées par géolocalisation.

Leur taux de réussite aux Core Web Vitals est passé de 45% à 92% après la migration.

Quand Jamstack est le mauvais choix

Je crois en être honnête sur les limitations. Jamstack n'est pas idéal pour :

  • Les applications hautement interactives en temps réel (pensez Google Docs, Figma) -- elles ont besoin de connexions persistantes au serveur, pas de pages pré-rendues.
  • Les sites où chaque page est unique par utilisateur -- si rien ne peut être en cache, vous perdez l'avantage du CDN. Bien que le SSR edge aide à combler cette lacune.
  • Les équipes sans capacité d'ingénierie frontend -- l'expérience de développement est super si vous avez des développeurs à l'aise avec React/Vue/Svelte et l'intégration d'API. Un responsable marketing solo est souvent mieux servi par Squarespace ou WordPress.
  • Le prototypage rapide où l'architecture ne compte pas encore -- si vous validez une idée la semaine prochaine, ne sur-concevez pas la stack.

Si vous êtes incertain quant à l'adéquation de Jamstack à votre projet, nous serions heureux de discuter des compromis. Contactez-nous ou vérifiez notre tarification pour les projets web sans tête.

FAQ

Jamstack est-il uniquement pour les sites statiques ?

Non -- et c'est l'idée fausse la plus courante. Bien que Jamstack soit originaire des sites statiques, le Jamstack moderne comprend ISR, les fonctions edge, et le rendu côté serveur au edge. Vous pouvez créer des expériences entièrement dynamiques et personnalisées.

La partie "statique" fait référence à la façon dont les pages sont livrées (fichiers pré-construits depuis un CDN), pas ce qu'elles peuvent faire.

Comment Jamstack gère-t-il le contenu dynamique comme les commentaires des utilisateurs ou les paniers d'achat ?

Via JavaScript côté client et les API. Les commentaires peuvent utiliser un service comme Disqus ou un endpoint API personnalisé. Les paniers d'achat utilisent généralement l'état côté client synchronisé avec une API e-commerce (Shopify, Snipcart, Medusa).

La page statique se charge instantanément, puis JavaScript hydrate les parties dynamiques.

Quelle est la différence entre un CMS sans tête et un CMS traditionnel ?

Un CMS traditionnel (comme WordPress dans son mode par défaut) gère le contenu et rend le frontend. Un CMS sans tête gère uniquement le contenu et le livre via API.

Votre frontend -- construit avec Next.js, Astro, ou n'importe quel framework -- consomme cette API. Ce découplage vous permet d'utiliser le même contenu sur les sites web, les applications mobiles, et d'autres canaux.

Combien coûte un site Jamstack à héberger ?

Significativement moins cher que l'hébergement traditionnel pour la plupart des sites. Vercel, Netlify, et Cloudflare Pages ont tous des niveaux gratuits généreux qui gèrent le trafic modéré.

Même à grande échelle, vous payez pour la bande passante du CDN (bon marché) plutôt que pour le calcul serveur (cher). Un site recevant 500K visites mensuelles pourrait coûter $0-$20/mois sur le plan Pro de Vercel. Le même trafic sur un hôte WordPress géré pourrait fonctionner à $50-$300/mois.

Jamstack fonctionne-t-il pour le SEO ?

Exceptionnellement bien. Les moteurs de recherche reçoivent du HTML entièrement rendu à la première requête -- pas besoin d'attendre que JavaScript s'exécute. Les améliorations de vitesse des pages impactent directement les scores des Core Web Vitals.

Les balises meta pré-rendues et les données structurées sont intégrées au HTML au moment de la construction. De nombreux professionnels du SEO recommandent spécifiquement les architectures Jamstack pour les sites de contenu.

Que se passe-t-il si mon CMS sans tête tombe en panne ?

C'est en fait l'un des points forts de Jamstack. Parce que votre site est pré-rendu et servi depuis un CDN, il reste en ligne même si votre CMS est temporairement indisponible.

Les éditeurs ne peuvent pas publier de nouveau contenu pendant la panne, mais votre site continue de servir la dernière version construite à tous les visiteurs. Comparez cela à WordPress traditionnel, où une panne de base de données signifie que votre site entier s'arrête.

Combien de temps faut-il pour migrer un site WordPress vers Jamstack ?

Cela dépend de la complexité. Un site marketing simple avec 50-100 pages pourrait prendre 4-8 semaines. Un grand site de contenu avec des milliers d'articles, des plugins personnalisés, et des flux de travail complexes pourrait prendre 3-6 mois.

La migration de contenu elle-même (WordPress vers CMS sans tête) est généralement la partie la plus facile -- des outils comme wp-graphql et les importateurs spécifiques aux CMS gèrent le travail lourd. La reconstruction du frontend est l'endroit où la plupart du temps s'écoule.

Les non-techniciens peuvent-ils gérer le contenu sur un site Jamstack ?

Absolument. C'est tout l'intérêt d'un CMS sans tête.

Les plateformes comme Storyblok offrent une édition visuelle par glisser-déposer. Le Studio de Sanity fournit une interface d'édition personnalisable. Du point de vue d'un éditeur, l'expérience est souvent meilleure que WordPress parce que le CMS est conçu spécifiquement pour la gestion de contenu sans le désordre des paramètres de thème, des configurations de plugin, et de la gestion de serveur.