Votre site de première année tient dans un dossier. Des fichiers .html, une feuille de style, quelques images. Vous déposez le dossier sur un serveur, il est en ligne.

C’est l’architecture la plus simple qui existe. C’est aussi celle du blog que vous êtes en train de lire.

Entre ce dossier et ce qu’on appelle un « stack moderne », il y a une trentaine d’années et quatre étapes. Chacune résout un problème précis de la précédente — et en introduit un nouveau. Les prendre dans l’ordre est le seul moyen de comprendre pourquoi la dernière a cette tête-là.

1. Le dossier de fichiers

graph TD
    N[Navigateur] -->|GET /page.html| S[Serveur de fichiers]
    S -->|le fichier, tel quel| N
    class S neutre

Le serveur ne calcule rien. Il trouve le fichier demandé et l’envoie.

Ce que ça règle : tout, tant que le site est petit. Rien ne tourne, donc rien ne plante. Pas de base de données, donc rien à attaquer. C’est rapide par construction — il n’y a aucun travail à faire.

Où ça bute : le contenu partagé. Votre menu est recopié dans chaque fichier. À quarante pages, ajouter une entrée au menu, c’est ouvrir quarante fichiers et n’en rater aucun. Et le jour où quelqu’un d’autre doit publier un article, il doit écrire du HTML.

2. Le serveur qui assemble

graph TD
    N[Navigateur] -->|GET /article/12| S[Serveur]
    S -->|HTML assemblé| N
    S <-->|requête| D[(Base)]
    class S attention

La page cesse d’exister comme fichier. Elle est fabriquée à chaque demande, à partir d’un gabarit et de données rangées dans une base.

Ce que ça règle : le menu vit à un seul endroit. Ajouter un article, c’est ajouter une ligne dans une base — pas un fichier. Et comme le contenu est séparé du code, on peut donner à quelqu’un une interface pour l’écrire sans jamais voir de HTML. C’est exactement ce qu’est WordPress, et c’est pourquoi il fait tourner une part énorme du web : il a résolu le problème de la personne qui publie.

Où ça bute : le serveur refait le même travail pour chaque visiteur. Mille personnes lisent le même article, la même page est assemblée mille fois, avec mille requêtes à la base — pour un contenu qui n’a pas changé depuis six mois. Sous charge, c’est ce qui tombe en premier.

Et côté navigateur, chaque clic recharge la page entière, y compris l’en-tête, le menu et le pied de page qui sont identiques.

3. Le navigateur qui assemble

graph TD
    N[Navigateur] -->|1. GET| S[Serveur]
    S -->|coquille vide + JS| N
    N -->|2. fetch| A[API]
    A <--> D[(Base)]
    A -->|JSON| N
    N -->|3. le JS assemble| E[Page affichée]
    class E attention

On inverse. Le serveur envoie une page presque vide et un programme JavaScript. C’est le navigateur qui va chercher les données et fabrique l’affichage — le cycle de l’article précédent sur les frameworks, appliqué à la page entière.

Ce que ça règle : la navigation ne recharge plus rien. Cliquer met à jour la partie qui change, et rien d’autre. Le serveur n’assemble plus de HTML, il répond des données — et les mêmes données peuvent servir une application mobile sans une ligne de plus.

Où ça bute : le premier chargement. L’utilisateur reçoit une page vide et regarde un écran blanc pendant que le JavaScript se télécharge puis s’exécute. Sur un téléphone en 4G moyenne, ça se compte en secondes.

Pire pour un site qui vit de sa visibilité : un moteur de recherche qui n’exécute pas le JavaScript voit exactement ce qu’a reçu le navigateur — une page vide.

4. Les deux à la fois

graph TD
    N[Navigateur] -->|GET| C[CDN
au plus près]
    C -->|page déjà rendue| N
    C -.->|hors cache| S[Rendu serveur]
    S <--> D[(Base)]
    N -->|le JS reprend la main| I[Interaction]
    class C ok
    class I neutre

L’étape 4 refuse de choisir. La page est rendue en HTML avant d’arriver dans le navigateur — soit à chaque requête sur le serveur, soit une fois pour toutes au moment de la construction du site. Le navigateur reçoit donc une page pleine, qui s’affiche tout de suite et qu’un moteur peut lire. Puis le JavaScript « reprend la main » et l’on retrouve l’interactivité de l’étape 3.

Le CDN sert ces pages depuis un serveur géographiquement proche du visiteur, ce qui supprime l’essentiel de l’attente réseau.

Ce que ça règle : le premier affichage rapide de l’étape 2, l’interaction de l’étape 3, la charge serveur de l’étape 1.

Où ça bute : le prix. Le même code s’exécute maintenant dans deux environnements — sur le serveur, où il n’y a pas de fenêtre ni de document, et dans le navigateur, où il y en a. Il faut une étape de construction. Et il apparaît une famille de bugs qui n’existent qu’à la couture entre les deux : ce que le serveur a rendu et ce que le navigateur recalcule ne coïncident pas tout à fait, et l’écran cligne ou se réorganise sous les yeux de l’utilisateur.

Ce que la séquence apprend

Relisez les quatre « où ça bute ». Aucune étape n’est meilleure que la précédente dans l’absolu : chacune échange un problème contre un autre.

Ce n’est donc pas une échelle sur laquelle il faudrait monter le plus haut possible. C’est une liste de compromis, et la seule question utile devant un projet est : lequel de ces problèmes est-ce que j’ai réellement ?

Votre situationL’étape qui suffit
Peu de pages, contenu qui bouge rarement, vous seul écrivez1
Quelqu’un qui n’écrit pas de code doit pouvoir publier2
Interface très interactive, ou une application mobile à servir aussi3
Beaucoup de trafic, beaucoup d’interaction, et il faut être indexé4

Choisir l’étape 4 pour un site de trois pages, c’est ajouter une chaîne de construction, deux environnements d’exécution et une classe entière de bugs — pour résoudre un problème que vous n’avez pas.

Et l’inverse est vrai aussi : tenir un site de mille pages à l’étape 1, à la main, c’est se condamner à oublier un fichier.

Un site qui a redescendu la séquence

Si c’était une échelle, personne ne la descendrait. MDN — la documentation web de Mozilla, que vous ouvrez probablement plusieurs fois par semaine — l’a fait.

Leur site tournait sur une application React, à l’étape 3, construite sur un outillage devenu difficile à maintenir. La refonte revient à des pages rendues avant d’arriver dans le navigateur, et le contenu est désormais transformé en amont par une chaîne de construction écrite pour ça, qui part de fichiers markdown.

Regardez le profil d’une documentation : du contenu qui change rarement, lu par beaucoup de monde, qui doit être indexé, et presque rien d’interactif. Relisez le tableau — ce n’est pas un profil d’étape 3. Ils sont redescendus là où leur problème se situait réellement, et une équipe de cette taille qui l’écrit publiquement vaut mieux que n’importe quel argument que je pourrais avancer ici.

Le cas de ce blog

Ce site est à l’étape 1, et le choix est délibéré. Le contenu ne change que quand j’écris un article, il n’y a qu’un auteur, et rien n’a besoin d’être interactif. Un générateur assemble les gabarits et les textes sur ma machine, et ce qui part en ligne est un dossier de fichiers — comment il y arrive est raconté ici.

Le menu n’est pourtant écrit qu’une fois. C’est la nuance que la séquence ci-dessus laisse de côté : la génération de site statique reprend le gabarit unique de l’étape 2, mais l’exécute avant la mise en ligne plutôt qu’à chaque visite. On garde le fichier plat, on perd la personne qui publie sans coder.

La question qui situe n’importe quel stack

Vous allez rencontrer beaucoup d’architectures — celle de votre stage, celle d’un tutoriel, celle qu’un camarade défendra avec conviction. Aucune n’est à juger sur sa modernité.

Quel problème cette couche résout-elle, et est-ce que je l’ai ?

Quand la réponse à la seconde moitié est non, la couche ne vous apporte rien. Elle vous coûte.

Pour aller plus loin

  • Under the hood of MDN’s new frontend — le récit complet de la refonte évoquée plus haut, par l’équipe qui l’a faite. Le meilleur exemple public de choix d’architecture assumés et expliqués.