Qu’est-ce que l’approche Jamstack : explications & conseils 

Quand on s’intéresse à l’architecture découplée, il faut savoir ce qu’est un CMS headless mais il est également très pertinent de se pencher sur l’approche Jamstack.  

En effet, la Jamstack s'impose comme une architecture web innovante, offrant rapidité, sécurité et scalabilité. Contrairement à une pile technique traditionnelle, la Jamstack repose sur trois piliers : JavaScript, API et Markup, permettant une séparation efficace entre le front-end et le back-end. Alors voyons en quoi consiste cette approche découplée, comment la mettre en place et qui a le plus à y gagner. 

Comprendre l'architecture Jamstack 

Jamstack : définition et principes  

Un ensemble de technologies 

On peut parler d’approche Jamstack ou d'architecture Jamstack ou plus simplement de la Jamstack. C’est l’acronyme des trois technologies qui la composent : 

• J pour JavaScript, le langage de programmation ; 

• A pour API, qui est déjà un sigle pour Application Programming Interface, c’est un ensemble de règles et de définitions que les applications peuvent suivre pour communiquer entre elles ; 

• M pour Markup, c’est le code HTML qui balise le contenu d’une page web. 

Dans une architecture Jamstack, front-end et back-end sont séparés : 

• Le front-end est pré-construit en tant que contenu statique et hébergé sur des CDN, à savoir des serveurs dédiés, géographiquement proches des utilisateurs. Ces derniers accèdent directement aux fichiers statiques, ce qui améliore la vitesse et la sécurité des applications ou du site. 

• La partie back-end se décompose en une multitude de services accessibles via des API, au lieu d’un serveur monolithique devant gérer tout simultanément. 

En effet, si le principe de base de la Jamstack c’est la génération de contenu statique, cela n’empêche pas que les sites modernes ont souvent besoin d’une partie dynamique. Par exemple, un panier d’achat sur un site d’e-commerce. Il existe des solutions à cette problématique sous la forme d’outils proposant des “dynamic island”, des bouts de site dynamiques qui font des appels API pour répondre aux actions de l’utilisateur. Par exemple, ajouter un article au panier. 

Comment ça marche : la SSG

Pour aller un peu plus en détail dans le fonctionnement, prenons l’exemple d’un blog de quelques dizaines de pages, utilisant la Jamstack : en amont du déploiement, au moment du build plus précisément, le blog crée toutes ses pages en générant du HTML, CSS et JS. Pour savoir lesquelles faire et comment les faire, il va piocher : 

• soit dans une base de données ; 

• soit dans un CMS ; 

• soit dans des fichiers du disque dur (par exemple des fichiers markdown). 

Une fois terminé, le build contient alors un dossier de fichiers prêts à être déployés en ligne sur n’importe quel serveur. Après déploiement, lorsque l’utilisateur visite une des pages du blog, il accède au fichier HTML correspondant sans qu’il n’y ait eu besoin de nouveaux appels API. C’est le processus SSG (Server Side Generation).

Stratégies alternatives SSR et CSR 

Il existe deux autres types fonctionnements :

• SSR (Server Side Rendering) : ici, la page est construite au moment où l’utilisateur visite la page du blog, pour reprendre notre exemple. C’est le serveur qui la construit, en allant puiser ce dont il a besoin dans une base de données. Puis il l’envoie au client (de l’utilisateur). C’est le processus utilisé pour les sites Wordpress et pour l’écrasante majorité des sites classiques ; 

• CSR (Client Side Rendering) : au moment où l’utilisateur visite la page, son navigateur récupère les informations de la base de données via une API et construit la page. 

Prenons un exemple pour comprendre en quoi l'approche Jamstack (SSG) diffère des deux autres. Imaginons un site e-commerce, et plus spécifiquement la page présentant une paire de baskets roses que notre utilisateur va visiter. Au moment de l'ouverture de la page, voici ce qu'il se passe :

• Dans l'approche CSR, le code Javascript (React, Vue, etc.) va calculer le HTML à afficher, puis va faire un appel API pour récupérer les informations sur notre paire de basket, avant de les afficher. On devra gérer le temps de chargement (avec des zones de chargement dédiées appelées Squeleton) ;

• Dans l'approche SSR, le serveur reçoit la demande d'affichage et va récupérer les informations sur les baskets en base de données avant de générer le HTML de la page et de le renvoyer à l'utilisateur. Pendant ce temps de calcul, le navigateur affiche une page blanche. Notez qu'on peut mettre en place un système de cache, pour éviter que le serveur ne recalcule la page de notre paire de baskets trop souvent ;

• Enfin avec l'approche Jamstack, l'utilisateur télécharge le HTML, CSS et JS et la page est affichée sans aucune autre requête API ou calcul.

Quand utiliser quelle stratégie ? 

L'approche Jamstack (SSG) est une option intéressante si l’on cherche à optimiser le référencement naturel (SEO) du contenu et que ce dernier n’est pas amené à changer trop souvent (car une modification nécessite un changement de build pour être déployée). Dans les faits cela signifie : 

• site statique (vitrine) ; 

• blog ; 

• site de presse ; 

• e-commerce limité à quelques produits ou services. 

À l’inverse, le SSR est à privilégier si le contenu change souvent ou s’il est massif. En effet, si on choisissait le SSG pour ce type de cas, alors on aurait une fréquence et un temps de construction des builds très élevés, ce qui donnerait en pratique des performances désastreuses. 

Enfin, le CSR s’adresse aux produits qui n’ont pas d’objectif SEO, qui sont extrêmement dynamiques (ce qui exclut le SSG) et pour lesquels les performances en termes de temps de chargement ne sont pas un enjeu de premier plan. Il s’agira essentiellement de SaaS professionnels tels que Jira, ClickUp ou Notion. 

Jamstack : quels avantages ?  

On met souvent en opposition architecture Jamstack et architecture traditionnelle. Pourquoi ? Parce que le premier modèle est découplé tandis que le second est monolithique. Ce sont donc deux approches radicalement différentes.  

Et pour cause, la Jamstack a été pensée pour répondre à des défis nouveaux et plus complexes : l’architecture monolithique fonctionnait à merveille quand les visiteurs utilisaient un seul type de machine (ordinateur) pour un seul type de contenu (du texte), mais le paradigme actuel n’est plus le même. D’où un certain nombre d’avantages de l’approche Jamstack aujourd’hui. 

Amélioration des performances 

Tout d’abord, dans Jamstack, le contenu du site est généré statiquement lors du processus de build : les pages web sont pré-construites et prêtes à être servies aux utilisateurs sans traitement supplémentaire côté serveur, ni côte client (contrairement à une web app classique où tout se joue dans le navigateur). 

Par conséquent, comme il n'y a pas besoin de générer dynamiquement du contenu à chaque requête utilisateur, les temps de chargement des pages sont considérablement réduits. 

De plus, une fois l’étape de “build” passée, un site créé avec la “Jamstack” a tout d’un site internet statique très classique : il peut être hébergé n’importe où, à moindre coût, sans besoin de puissance de calcul côté serveur. 

Ces derniers, situés dans divers endroits géographiques, rapprochent le contenu de l'utilisateur final. Cela réduit encore la latence et accélère davantage le chargement des pages. 

De meilleures performances apportent deux bénéfices majeurs :  

• l’expérience utilisateur est meilleure car plus fluide ; 

• la charge sur les serveurs est réduite, permettant de mieux gérer les pics de trafic sans dégrader les performances. Cela conduit à une meilleure scalabilité du site. 

Sécurité 

Côté cybersécurité, la Jamstack n’est pas non plus en reste. En effet, rappelez-vous : les applications Jamstack ne fonctionnent pas avec des serveurs dynamiques constamment exposés à Internet via des mises à jour. Au contraire, le contenu est statique et fourni par des CDNs.  

De ce fait, la surface d'attaque est considérablement réduite, ce qui diminue les risques d'attaques courantes telles que :  

• les injections SQL ;  

• les scripts intersites (XSS) ;  

• Les attaques bruteforce. 

En outre, côté serveur, grâce au design découplé, les API peuvent être sécurisées de manière indépendante, avec des contrôles d'accès et d’authentification plus résistants et des mécanismes de chiffrement.  

Enfin, parmi tous les microservices constituant le back-end, certains (les plus simples) sont gérés par des fonctions serverless. Ce sont des fragments de code qui s'exécutent en réponse à des événements sans nécessiter de serveur dédié. Par exemple :  

• un redimensionnement ou une conversion de format de fichier d’image au moment du téléchargement ; 

• un envoi d’e-mail d’invitation à un séminaire lorsqu’un formulaire d’inscription a été rempli ; 

• la suppression de données obsolètes à échéances régulières programmées.  

Ces fonctions sont non seulement inactives lorsqu'elles ne sont pas utilisées mais elles ont également une durée de vie limitée. Ce qui réduit encore plus les fenêtres d’opportunité pendant lesquelles les cybercriminels pourraient passer à l’action. Sans compter que les fournisseurs de services serverless offrent des mesures de sécurité avancées intégrées à leurs programmes. 

Les bonnes pratiques pour appliquer l’approche Jamstack 

Ainsi, l’approche Jamstack permet de créer des sites web rapides, sécurisés et scalables, mais pour en bénéficier, quelques bonnes pratiques sont à connaître et à mettre en place. 

L’utilisation d’un CDN (Content Delivery Network) 

On l’a déjà vu, un CDN est un serveur qui permet de distribuer le contenu de manière rapide et efficace en répliquant les fichiers statiques sur plusieurs serveurs situés à divers endroits du globe. 

C’est une mesure centrale et, dans les faits, complètement indispensable à toute implémentation d’une architecture Jamstack. Sans CDN, il devient difficile d’optimiser les latences serveur et les temps de chargement pour le visiteur. 

Techniques pour minimiser les temps de build et de déploiement 

Première technique : le déploiement atomique. Son objectif est de faire en sorte que les mises à jour du site soient toutes publiées en une seule opération. Cela évite :  

• les incohérences ;  

• les périodes d’indisponibilité du site ou de l’application au moment du déploiement ; 

• l’affichage d’une version partiellement dysfonctionnelle du site côté utilisateur. 

Ensuite, il y a les incremental builds. Certains générateurs de contenu statique, comme l’outil Gatsby, créent des builds par incrémentation. C'est-à-dire que pour chaque nouveau build, seules les pages modifiées sont reconstruites. Ce qui fait gagner beaucoup de temps. 

Pipeline CI/CD : configuration et automatisation 

Un pipeline CI/CD est tout une série de démarches à effectuer dans un ordre précis pour distribuer et déployer une nouvelle version (un nouveau build) d’un site ou d’une application. D’où le nom : Continuous Integration/Continuous Deployment. 

Nul besoin de construire votre propre pipeline de zéro, il existe des plateformes telles que Netlify ou Vercel qui proposent des solutions CI/CD clé-en-main. Vous pourrez ainsi facilement configurer puis automatiser les processus de :  

• build ; 

• test ; 

• déploiement 

Et ce, à chaque fois qu’une modification est poussée vers le dépôt. 

Caching et pré-rendu 

Un autre excellent moyen de réduire la charge sur les serveurs et améliorer les temps de réponse est d’optimiser le caching : 

• configurer les en-têtes HTTP pour contrôler le cache des navigateurs ;  

• utiliser les caches des CDN pour les fichiers statiques. 

Des techniques de pré-rendu peuvent aussi vous servir à réduire la latence et améliorer la performance globale du site web ou de l’application. On pense ainsi par exemple au pré-rendu à la construction (pre-generated pages) ou au pré-rendu à la demande (statically generated pages on request), afin de servir des pages directement prêtes à l’emploi.  

Pour quels sites l’approche Jamstack est-elle appropriée ? 

Petite boutique en ligne 

Dans le cas où votre site e-commerce ne serait pas une immense machine au contenu dynamique et changeant, l’approche Jamstack peut être pertinente : 

• Dans le cas où vous auriez un énorme catalogue, le SSG (server side generation = Jamstack) peut être difficile à gérer. 

• Le SSR (server side rendering) est plus couteux en ressource, mais plus flexible si vous souhaitez gérer votre petite boutique avec l’approche Jamstack. 

Grâce à la Jamstack, les pages de produits peuvent être pré-générées statiquement, assurant des temps de chargement rapides. Les interactions dynamiques, comme les paniers d'achats et les paiements, peuvent être gérées via des API sécurisées.  

Par exemple, lorsqu'un utilisateur ajoute un produit au panier, une fonction serverless peut être déclenchée pour mettre à jour le panier en temps réel. En outre, les mises à jour du catalogue de produits peuvent être effectuées via un CMS (Content Management System) headless, déclenchant automatiquement une nouvelle génération statique des pages concernées. 

Site vitrine Wordpress 

La plupart des sites vitrines sont quasi exclusivement composés de pages statiques. Le contenu porte sur l’entreprise, ses services ou ses produits et parfois sur l’équipe. Dans tous les cas, ce sont des informations qui changent peu fréquemment, il n’y a donc pas besoin de générer des builds en permanence. 

Si l’on ajoute à ça le besoin d’un bon référencement pour le site, la Jamstack et plus précisément la Jamstack en SSG apparaît comme la solution idéale. 

Blog ou site de presse 

Ici encore, le contenu n’est pas modifié en permanence et il y a des exigences de SEO. Par ailleurs, en particulier pour les sites de presse, on peut parfois observer des pics de trafic lorsqu'un article a beaucoup de succès. C’est dans des situations comme ça où la scalabilité est de mise et que l’approche Jamstack brille : grâce à la distribution via CDN, il n’y a pas de risque de surcharge serveur. 

Finalement, l’architecture Jamstack n’est pas l’innovation technologique d’une seule idée, mais toute une philosophie de flexibilité avec une myriade de possibilités pour moduler la construction et le service des pages de son site web. Mais attention, l’approche Jamstack est loin d’être adapté à tous les cas d’usage : back-office, Saas très dynamique, etc... Il faut donc être conscient des limites de chaque approche. 

Chez Lonestone, nous vous accompagnons dans tous vos projets web en mettant à votre disposition tout notre savoir et notre expertise en matière de développement aussi bien web que mobile. Découvrez-nous ! 

À retenir : L’approche Jamstack 

Qu’est-ce que CDN veut dire dans une approche Jamstack ? 

CDN veut dire "Content Delivery Network" (littéralement, réseau de distribution de contenu). Dans une approche Jamstack, le CDN est un ensemble de serveurs qui sert à distribuer le contenu statique du site web à partir de plusieurs serveurs dans diverses localisations géographiques. L’idée est que chaque utilisateur, quel que soit son continent, ait un serveur assez proche afin de réduire la latence et d'améliorer les temps de chargement. 

Qu’est-ce que l’architecture Jamstack ? 

C’est une approche qui combine 3 technologies : JavaScript, API, Markup. Les pages sont pré-générées en contenu statique, les interactions dynamiques sont gérées par JavaScript côté client, et les fonctionnalités serveur sont fournies par des API. Résultat : de meilleures performances (car les ressources sont optimisées), le site est facilement scalable, la cybersécurité est renforcée. 

Qu’est-ce que le balisage dans Jamstack ? 

Le balisage, ou "Markup", dans Jamstack fait référence au code HTML qui structure le contenu des pages web. Dans cette approche, le balisage est souvent pré-généré statiquement lors du processus de build, ce qui permet de servir des pages prêtes à l'emploi directement à partir d'un CDN. Cela améliore les temps de chargement et offre une expérience utilisateur plus rapide mais aussi plus fiable.