Deux façons de livrer un frontend : fichiers statiques ou serveur actif

Lorsque vous commencez à construire une application frontend, une question va façonner l'ensemble de votre pipeline de déploiement bien plus que le choix du framework : cette application a-t-elle besoin d'un serveur qui reste actif, ou peut-elle vivre sous forme d'un simple dossier de fichiers ?

Ce n'est pas un débat d'architecture théorique. C'est une décision pratique qui détermine comment vous construisez, où vous déployez, ce qui peut mal tourner et comment le corriger.

Le frontend statique : des fichiers qui parlent d'eux-mêmes

Imaginez que vous construisez une page de profil d'entreprise, un site de documentation ou une page d'atterrissage marketing. Vous écrivez du HTML, ajoutez du CSS, quelques images, et vous téléchargez le tout quelque part. Le navigateur télécharge ces fichiers et les affiche. Terminé.

C'est un frontend statique. Tout ce dont le navigateur a besoin est prêt au moment de la construction. HTML, CSS, JavaScript, polices, images — tout devient des fichiers qui peuvent reposer sur un serveur web basique, un CDN ou un bucket S3. Aucun processus serveur ne tourne après le déploiement. Pas d'attente pour qu'un runtime démarre. Les fichiers sont juste là, attendant d'être servis.

Mais statique ne veut pas dire simple. Une application React ou Vue qui récupère des données depuis une API peut toujours être construite en fichiers statiques. La différence est que les données n'apparaissent pas tant que le navigateur n'exécute pas le JavaScript et ne fait pas d'appels API. C'est ce qu'on appelle le rendu côté client. Le HTML initial peut être une coquille vide, et le contenu réel se remplit après le chargement de la page.

Le pipeline pour un frontend statique est simple :

  1. Exécuter la commande de build.
  2. Récupérer les fichiers de sortie.
  3. Les télécharger vers un stockage ou un CDN.

Pas de redémarrage de serveur. Pas de health check. Pas d'attente qu'un processus soit prêt. Le déploiement peut être aussi simple que remplacer des fichiers dans un bucket ou mettre à jour un pointeur CDN. Si quelque chose tourne mal, vous revenez aux fichiers précédents. C'est rapide, peu coûteux et difficile à casser.

Le frontend SSR : des pages cuisinées à la demande

Considérez maintenant un site e-commerce qui affiche des prix en temps réel, la disponibilité des stocks et des recommandations personnalisées. Si vous le construisez en fichiers statiques, les utilisateurs verront des données obsolètes jusqu'à ce que le navigateur exécute JavaScript et récupère des informations fraîches. Ce délai peut faire perdre des ventes, embrouiller les clients et donner une impression de lenteur.

C'est là qu'intervient le rendu côté serveur (SSR). Quand un utilisateur demande une page, le serveur récupère les dernières données, génère le HTML et envoie une page complète au navigateur. L'utilisateur voit le contenu immédiatement, sans attendre que le JavaScript se charge et s'exécute.

Le SSR signifie que votre frontend n'est plus seulement des fichiers. C'est une application en cours d'exécution qui a besoin d'un serveur, de dépendances, de variables d'environnement et de séquences de démarrage appropriées. Le pipeline ressemble désormais davantage à un déploiement backend :

  1. Construire l'application en code prêt pour le serveur.
  2. Installer les dépendances d'exécution.
  3. Configurer les variables d'environnement pour l'environnement cible.
  4. Démarrer le processus serveur ou déployer dans un conteneur.
  5. Exécuter des health checks pour confirmer que le serveur accepte les requêtes.
  6. Router le trafic vers la nouvelle version.
  7. Surveiller les erreurs après le basculement.

Si quelque chose tourne mal, le rollback signifie revenir à la version du serveur, pas seulement échanger des fichiers. Vous devez gérer les connexions à la base de données, l'état de session et l'invalidation de cache. C'est plus complexe, mais nécessaire quand les utilisateurs ont besoin de données fraîches à chaque chargement de page.

Le juste milieu : la génération de site statique

Il existe une approche hybride appelée génération de site statique (SSG). Elle ressemble au SSR pendant la construction mais se comporte comme un site statique à l'exécution. Le rendu a lieu une fois pendant le build, pas à chaque requête. Le résultat est un ensemble de fichiers HTML pré-rendus qui peuvent être servis de manière statique.

Le SSG fonctionne bien pour du contenu qui ne change pas toutes les secondes. Articles de blog, pages de documentation, pages produits récupérées depuis un CMS — tout cela peut être rendu au moment du build et servi comme fichiers statiques. L'utilisateur obtient des pages rapides, et vous évitez de gérer un runtime serveur.

Mais le SSG a un compromis. Si votre contenu change fréquemment, vous devez reconstruire et redéployer l'intégralité du site. Pour un blog avec un nouvel article par semaine, c'est acceptable. Pour un site e-commerce avec des mises à jour d'inventaire toutes les minutes, le SSG devient impraticable.

Ce que cela signifie pour votre pipeline

Le choix entre statique, SSR et SSG ne concerne pas seulement l'architecture. Il s'agit de la fréquence à laquelle votre contenu change, de la rapidité avec laquelle les utilisateurs doivent voir les mises à jour et de la charge opérationnelle que votre équipe peut gérer.

Voici une façon rapide d'y penser :

Le diagramme ci-dessous vous guide dans la décision et montre le pipeline correspondant pour chaque chemin.

flowchart TD A[L'application a-t-elle besoin d'un serveur ?] -->|Non| B[Frontend statique] A -->|Oui| C[Le contenu change constamment ?] C -->|Non| D[SSG - Génération de site statique] C -->|Oui| E[SSR - Rendu côté serveur] B --> F[Construire les fichiers statiques] F --> G[Télécharger vers CDN / S3] G --> H[Servir les fichiers] D --> I[Construire et pré-rendre le HTML] I --> J[Télécharger la sortie statique] J --> K[Servir comme fichiers statiques] E --> L[Construire le code serveur] L --> M[Installer les dépendances d'exécution] M --> N[Démarrer le processus serveur] N --> O[Health check et routage du trafic]
  • Statique : Le contenu change rarement. Les utilisateurs peuvent tolérer un petit délai avant l'affichage des données. Vous voulez le déploiement le plus simple possible.
  • SSR : Le contenu change constamment. Les utilisateurs ont besoin de données fraîches à chaque chargement de page. Vous êtes prêt à gérer un runtime serveur.
  • SSG : Le contenu change périodiquement. Vous voulez des pages rapides sans exécuter de serveur. Vous pouvez reconstruire le site lors des mises à jour de contenu.

Votre pipeline doit suivre cette décision, pas la combattre. Si vous choisissez le statique, n'ajoutez pas de gestion de serveur inutile. Si vous choisissez le SSR, ne faites pas comme si ce n'était qu'un dossier de fichiers.

Une checklist pratique avant de décider

Avant de vous engager dans une stratégie de déploiement, répondez à ces questions :

  • À quelle fréquence le contenu de cette page change-t-il ? Toutes les secondes, toutes les heures ou toutes les semaines ?
  • Les utilisateurs peuvent-ils attendre que le JavaScript récupère les données après le chargement de la page, ou ont-ils besoin du contenu immédiatement ?
  • Votre équipe a-t-elle la capacité de gérer un runtime serveur, y compris la surveillance, les redémarrages et les rollbacks ?
  • À quelle vitesse devez-vous récupérer après un mauvais déploiement ? Échanger des fichiers est plus rapide que redémarrer un serveur.
  • La même page aura-t-elle un aspect différent pour différents utilisateurs en fonction de leur session ou de leur localisation ?

Vos réponses vous orienteront vers la bonne approche. Ne laissez pas le framework ou le battage médiatique décider pour vous.

L'essentiel à retenir

Un frontend statique est un dossier de fichiers. Un frontend SSR est une application en cours d'exécution. Traitez-les différemment dans votre pipeline, et vous éviterez une complexité inutile ou l'omission d'étapes critiques. Commencez par l'approche la plus simple qui répond au besoin de contenu frais de vos utilisateurs, et n'ajoutez le rendu côté serveur que lorsque les données l'exigent.