Le commit part, le pipeline CI termine en quarante secondes, le CDN se met à jour. La démo impressionne la direction : pages ultra-rapides, déploiement automatique, zéro serveur « visible ». Deux semaines plus tard, la recherche full-text ne remonte rien parce qu'elle appelait une API Elasticsearch absente du devis. Les comptes clients passent par Auth0. Le panier interroge une API stock hébergée ailleurs. Le « site statique » cache en réalité cinq services dynamiques jamais budgétés ni monitorés.
La promesse Jamstack — JavaScript, APIs, Markup — tient quand on pré-génère le HTML et qu'on le sert depuis un réseau de diffusion proche. Publication rapide, bonne résilience face aux pics, charge faible sur l'origine pour le contenu statique. L'erreur classique consiste à croire que tout devient statique alors que panier, authentification, commentaires, recherche et prix temps réel restent dynamiques par nature.
Jamstack accélère la diffusion ; il ne supprime pas la cartographie des backends. Avant le premier git push, listez ce qui reste vivant — et où ça tourne.
Ce qui reste statique et ce qui ne le peut pas
Le build peut produire en amont les articles de blog, les landing pages traduites, la documentation produit stable et les assets optimisés. En revanche, dès qu'un visiteur se connecte, filtre un catalogue en direct ou paie en ligne, vous sortez du pur statique. Le panier, la session utilisateur, la recherche instantanée, les formulaires avec validation serveur et les webhooks de paiement exigent une brique dynamique quelque part — serverless, API dédiée, base managée ou service tiers.
Cette frontière n'est pas théorique : elle détermine votre budget hébergement, votre surface de sécurité et votre plan de supervision. Un site marketing entièrement statique coûte peu à diffuser. Une plateforme avec comptes et recherche coûte ce que coûtent ses APIs, qu'elles soient visibles ou noyées dans le discours « serverless inclus ».
Hébergement : trois couches à séparer
Une architecture Jamstack crédible distingue au minimum trois couches. Le dépôt Git alimente un build CI — GitHub Actions, GitLab CI ou l'intégration native de la plateforme. L'hébergeur front — Netlify, Vercel, Cloudflare Pages, S3 avec CloudFront — sert le HTML et les assets depuis le CDN. Enfin, le CMS headless ou Git-based, plus les services dynamiques, vivent souvent sur d'autres comptes : Sanity, Contentful, Strapi, une API Laravel sur VPS, une base Postgres managée.
Pour un pur site vitrine sans CMS distant, le guide site statique suffit. Dès qu'une équipe éditoriale touche au contenu via interface web, le découpage décrit dans CMS headless devient central. Ne mélangez pas la facturation CDN avec celle du CMS : deux contrats, deux SLA, deux régions possibles.
Preview, fraîcheur et coûts que la démo oublie
Les branches de preview — une URL par pull request pour les rédacteurs — sont parfois incluses, parfois facturées au build-minute. Sur un gros site, un déploiement complet peut prendre plusieurs minutes ; d'où l'intérêt des builds incrémentaux, de la régénération statique incrémentale ou de la revalidation à la demande sur Next.js et équivalents. La fraîcheur éditoriale se négocie entre coût de build et délai acceptable : une publication toutes les heures n'a pas les mêmes contraintes qu'un fil d'actualité minute par minute.
Les médias lourds et les appels API hors CDN principal peuvent aussi gonfler la facture de sortie réseau. Si vos images transitent par un bucket dans une région éloignée de vos visiteurs, le CDN ne compense pas tout. Le guide choisir une région cloud s'applique autant au stockage qu'au front.
Le sommet : la vitesse de déploiement masque la cartographie des APIs
Comparez plateformes edge et hébergeurs de stockage objet via notre annuaire et le comparateur en filtrant région, build minutes et fonctions serverless.
Décider et avancer sans angle mort
Commencez par dresser la liste exhaustive des pages réellement statiques et des flux qui exigent une API ou une base de données. Choisissez ensuite une stratégie de fraîcheur — régénération incrémentale, webhook CMS, rendu partiel côté serveur — adaptée à la cadence éditoriale réelle, pas à la cadence idéale du slide deck. Budgetez en parallèle les minutes de build, les invocations de fonctions et l'abonnement CMS, pas seulement le CDN. Testez la preview rédactionnelle avant le lancement : si les auteurs ne peuvent pas valider une page sans déployer toute la branche main, le workflow cassera en production. Enfin, documentez qui répond si l'API de recherche tombe un vendredi soir — le front statique restera en ligne, mais le site sera incomplet.
Questions fréquentes
Jamstack signifie-t-il zéro serveur ?
Non. Le HTML peut être pré-généré et servi depuis un CDN, mais l'authentification, la recherche, les paiements et les données temps réel passent encore par des API ou des fonctions. Jamstack décrit surtout la diffusion du markup, pas l'absence de dynamique.
Comment gérer le contenu mis à jour plusieurs fois par jour ?
Un rebuild complet à chaque modification ne tient pas la charge éditoriale. Utilisez la régénération statique incrémentale, la revalidation à la demande ou un rendu hybride, couplés à des webhooks CMS qui ne reconstruisent que les pages concernées.
Où héberger un site Jamstack ?
Le front statique convient bien à Netlify, Vercel, Cloudflare Pages ou un bucket objet avec CDN. Le CMS headless, les bases et les services d'auth restent souvent sur d'autres briques — consultez le guide CMS headless et celui sur le site statique.
Jamstack et formulaires de contact ?
Une page statique ne traite pas un POST seule sans couche dynamique. Il faut une fonction serverless, une petite API ou un service tiers — sinon le formulaire reste une coquille vide côté serveur.
Avant de dire « on est en Jamstack », posez une seule question : quoi reste dynamique, et où ça tourne ? Sans cette liste, vous n'avez qu'un CDN — pas une architecture.