L’architecture des applications web#

Le web a été conçu comme un système de documents. Un navigateur envoie une requête HTTP à un serveur, qui répond avec un document HTML. L’utilisateur clique sur un lien, le navigateur envoie une nouvelle requête, et reçoit un nouveau document. Ce modèle requête-réponse, simple et élégant, a fonctionné remarquablement bien pour le web documentaire. Mais à mesure que le web s’est transformé en plateforme d’applications, ce modèle a montré ses limites. Comment construire une boîte de réception Gmail, avec ses messages qui apparaissent en temps réel, dans un système conçu pour afficher des pages statiques ? La réponse à cette question a donné lieu à une succession d’architectures, chacune tentant de résoudre les problèmes de la précédente.

Le rendu côté serveur (SSR) traditionnel#

Dans le modèle originel du web, toute la logique vit sur le serveur. Quand l’utilisateur remplit un formulaire et clique sur “Soumettre”, le navigateur envoie les données au serveur via une requête HTTP POST. Le serveur traite la requête, interroge la base de données si nécessaire, génère une page HTML complète avec le résultat, et la renvoie au navigateur. Celui-ci jette tout ce qu’il affichait et dessine la nouvelle page de zéro. C’est le modèle que les frameworks web classiques comme PHP, Django (Python), Rails (Ruby) ou ASP.NET ont popularisé.

Ce modèle a des qualités réelles. Il est simple à comprendre : chaque URL correspond à une page, chaque action génère une nouvelle page. Le serveur contrôle tout, ce qui simplifie la sécurité et le référencement (les moteurs de recherche peuvent lire le HTML directement). Mais l’expérience utilisateur est limitée : chaque interaction provoque un rechargement complet de la page, avec un écran blanc fugace. Pour un blog ou un site vitrine, c’est parfaitement acceptable. Pour une application interactive comme un client email ou un tableur, ça devient vite frustrant.

AJAX et le tournant vers l’interactivité#

On a mentionné AJAX dans la section précédente comme une technique clé du Web 2.0. Regardons de plus près ce que ça change du point de vue architectural. AJAX (Asynchronous JavaScript and XML) permet au code JavaScript qui s’exécute dans le navigateur d’envoyer des requêtes HTTP au serveur en arrière-plan, sans recharger la page. Le serveur ne renvoie plus une page HTML complète, mais seulement les données demandées (souvent en JSON). Le JavaScript côté client se charge ensuite de mettre à jour le morceau de page concerné.

C’est un changement fondamental. Avec le SSR traditionnel, le navigateur est un simple afficheur : il reçoit du HTML et le dessine. Avec AJAX, le navigateur devient un acteur : il contient du code qui prend des décisions, envoie des requêtes et manipule l’interface. La logique de l’application commence à se partager entre le serveur et le client. Ce partage crée une tension architecturale qui va structurer toutes les évolutions suivantes du développement web : combien de logique mettre côté client, et combien garder côté serveur ?

Les Single Page Applications (SPA)#

La réponse la plus radicale à cette tension est de basculer toute la logique d’interface côté client. C’est le principe de la Single Page Application (SPA) : le serveur envoie une seule page HTML, quasi vide, accompagnée d’un gros fichier JavaScript. Ce JavaScript prend ensuite le contrôle complet de l’interface. Il gère la navigation (quand l’utilisateur clique sur un lien, c’est le JavaScript qui change le contenu affiché, sans requête au serveur pour une nouvelle page), il gère l’état de l’application (les données affichées, les formulaires en cours, les notifications), et il communique avec le serveur uniquement via des appels API pour récupérer ou envoyer des données.

Le résultat est une expérience fluide qui se rapproche de celle d’une application desktop : pas de rechargement de page, des transitions instantanées, une interface réactive. Gmail, Google Maps, Trello, Spotify Web sont tous des SPA. Mais cette approche a un coût. Le chargement initial est lent : le navigateur doit télécharger, analyser et exécuter tout le JavaScript avant d’afficher quoi que ce soit. Le référencement est problématique : les moteurs de recherche reçoivent une page quasi vide. L’historique de navigation et le bouton “retour” du navigateur, conçus pour des pages distinctes, doivent être émulés par le JavaScript. Et la complexité du code côté client explose : il faut gérer l’état, le routage, la synchronisation avec le serveur, le cache, les erreurs réseau. On a, en quelque sorte, réinventé les problèmes des applications desktop, mais dans le navigateur. Les SPA sont typiquement construites à l’aide de frameworks JavaScript comme Angular, React ou Vue.js, qu’on examinera en détail dans la section suivante.

Le retour du SSR et les approches hybrides#

Face aux limites des SPA, l’industrie a opéré un mouvement de balancier vers le milieu des années 2010. L’idée : et si on pouvait avoir le meilleur des deux mondes ? Le SSR pour le chargement initial (le serveur génère le HTML complet, ce qui est rapide à afficher et bon pour le référencement), puis le JavaScript qui prend le relais pour rendre la page interactive. C’est le principe de l’hydration : le serveur envoie une page HTML “prête à lire”, et le JavaScript côté client vient ensuite “hydrater” cette page en y attachant les comportements interactifs (les callbacks, la gestion d’état, etc.).

Ce modèle hybride est celui des frameworks dits “meta-frameworks” ou “full-stack” : Next.js (basé sur React), Nuxt (basé sur Vue.js), SvelteKit (basé sur Svelte). Ces outils permettent au développeur de choisir, page par page, quelle stratégie de rendu utiliser. Une page marketing peut être générée côté serveur pour le référencement, tandis qu’un tableau de bord interactif peut fonctionner comme une SPA. Cette flexibilité a un prix : la complexité du modèle mental. Le développeur doit comprendre où s’exécute chaque morceau de code (serveur ou client ?), comment les données transitent entre les deux, et comment l’hydration peut parfois causer des incohérences visuelles (un flash de contenu différent entre la version serveur et la version client).

La génération de sites statiques (SSG)#

Il existe une catégorie de sites web pour lesquels ni le SSR dynamique ni le SPA ne sont la bonne réponse : les sites dont le contenu change rarement. Un blog, une documentation technique, un site vitrine d’entreprise n’ont pas besoin de générer leur HTML à chaque requête. L’idée de la Static Site Generation (SSG) est de générer toutes les pages HTML à l’avance, au moment du build, puis de les servir directement comme des fichiers statiques. Pas de serveur applicatif, pas de base de données à interroger en temps réel : juste des fichiers HTML, CSS et JavaScript hébergés sur un CDN (Content Delivery Network).

Ce modèle, popularisé sous le nom de Jamstack (JavaScript, APIs, Markup), combine des pages statiques pré-générées avec des appels API côté client pour les parties dynamiques (commentaires, formulaires, recherche). Des outils comme Hugo (utilisé pour ce cours), Jekyll, Gatsby ou Astro permettent de générer des sites statiques à partir de fichiers Markdown ou de données provenant d’un CMS. L’avantage est triple : la performance (servir un fichier statique est quasi instantané), la sécurité (pas de serveur applicatif à attaquer), et la simplicité de déploiement (un simple hébergement de fichiers suffit). La limite est évidente : dès que le contenu devient très dynamique ou personnalisé par utilisateur, le modèle statique atteint ses limites et il faut revenir à une forme de rendu côté serveur ou côté client.