Paradigmes du frontend : comment choisir l'architecture de votre application web

Avant de choisir un outil, choisissez un paradigme

Lorsqu'une équipe débat de « React ou Angular ? », elle débat souvent de la mauvaise question. La décision qui coûte réellement des années de maintenance est autre : où et quand l'écran est assemblé. Dans le navigateur de l'utilisateur ? Sur un serveur, à chaque visite ? Une seule fois, à la construction du site ? S'agit-il d'une application installée sur l'ordinateur ou sur le téléphone ?

Chaque réponse est un paradigme, avec des avantages réels et des coûts qui n'apparaissent pas dans la démonstration. Cet article est une carte pour un CTO ou un directeur digital : ce qu'est chaque paradigme, quand il convient selon l'entreprise, ce qu'il coûte réellement et comment en sortir sans tout réécrire. C'est un critère de jugement, pas une recette.

1. Application monopage (SPA)

MDN la définit comme une application web qui charge un seul document et met à jour son contenu avec JavaScript lorsqu'il faut afficher autre chose. L'avantage : l'utilisateur navigue sans recharger de pages entières, avec une expérience plus dynamique. Et MDN en nomme aussi le coût : le SEO, un effort accru pour maintenir l'état et la navigation, et pour mesurer la performance de manière significative.

La documentation de React en ajoute un autre : les SPA sont faciles à démarrer, mais leur chargement initial peut être plus lent, et si chaque composant demande ses données après s'être affiché, il se forme des « cascades » de requêtes, où chaque étape attend la précédente.

Où elle convient : les systèmes internes et les tableaux de bord derrière une authentification, et tout produit à l'interaction très intense où arriver depuis un moteur de recherche n'est pas la priorité : là, l'interaction pèse plus que le premier chargement.

2. Rendu côté serveur (SSR)

Le serveur assemble le HTML à chaque requête et l'envoie déjà prêt. Angular le résume ainsi : le serveur répond avec un document rendu, ce qui donne des chargements plus rapides que le rendu côté client et un HTML complet pour les robots d'exploration. web.dev nomme le contrepoids : le premier octet peut arriver plus tard, car le serveur doit travailler avant de répondre.

Une nuance mérite d'être comprise : la page « paraît » prête avant d'être interactive. web.dev le décrit comme l'hydratation : tant que le JavaScript n'a pas terminé, la page semble prête, mais ses fonctions interactives ne répondent pas encore.

Où il convient : les pages publiques au contenu qui change selon la visite ou l'utilisateur et qui compte pour les moteurs de recherche.

3. Génération statique (SSG)

Le HTML de chaque URL est généré une seule fois, à la construction du site. Selon web.dev, cela donne des temps de réponse constamment rapides et permet de le servir depuis un réseau de diffusion de contenu (CDN) ; selon Angular, le site peut être déployé avec un simple CDN ou un serveur de fichiers, sans maintenir de serveur propre. La limite figure aussi chez web.dev : elle est inapplicable lorsqu'il y a des millions de pages uniques, et elle exige de connaître les URL à l'avance.

Où elle convient : les sites d'entreprise, la documentation, les blogs, les catalogues qui changent peu.

4. Hybrides et îlots

La pratique réelle est rarement « l'un ou l'autre ». Angular décrit le rendu hybride comme la combinaison du serveur, du statique et du client, route par route. Next.js l'exprime avec des composants serveur et client : par défaut, les pages et les layouts sont assemblés sur le serveur, et seul ce qui a besoin d'état, d'événements ou d'API du navigateur est marqué comme composant client, ce qui envoie moins de JavaScript.

// Illustratif, tiré de la documentation de Next.js : la page est assemblée sur le serveur
// et seul le bouton (marqué avec 'use client') est interactif dans le navigateur.
<LikeButton likes={post.likes} />

L'architecture en îlots pousse l'idée à l'extrême. La documentation d'Astro la décrit ainsi : l'essentiel de la page est du HTML statique et seuls de petits « îlots » reçoivent du JavaScript, uniquement là où il le faut.

Où elle convient : presque tout produit public comportant des zones interactives : un catalogue statique avec un simulateur de devis, un site de contenu avec un panier.

5. Micro-frontends

Ils découpent une grande application en parties que des équipes distinctes construisent et livrent séparément. La documentation de single-spa les appelle « un microservice dans le navigateur », chacun avec son dépôt et sa construction ; Module Federation, de webpack, permet à des compilations séparées de former une seule application et de partager des dépendances.

Or, ce que ces pages ne disent pas et que nous disons : un micro-frontend résout un problème d'organisation, non de technologie (notre critère ; les sources citées décrivent des bénéfices et non des coûts). Il a du sens lorsque plusieurs équipes, aux rythmes de livraison différents, se heurtent dans une même base de code. Avec une petite équipe, il ajoute des coutures que quelqu'un doit entretenir : versions partagées des bibliothèques, cohérence visuelle entre les parties et une expérience qui ne donne pas l'impression d'être cousue.

Et il y a un coût qui atteint l'utilisateur : si chaque équipe charge ses propres copies des mêmes bibliothèques, le navigateur télécharge plusieurs fois la même chose. Les sources elles-mêmes recommandent de partager les instances des grandes bibliothèques ; que cela se produise dépend de la coordination des équipes, et se vérifie avec les signaux de performance que nous mentionnons plus bas.

6. Applications de bureau et mobiles multiplateformes

Lorsque le navigateur ne suffit pas, il existe trois voies de nature différente :

• Application web installable (PWA). Selon MDN et web.dev, c'est une application construite avec des technologies web qui s'installe, peut fonctionner sans réseau, recevoir des notifications et utiliser le plein écran, avec une seule base de code. MDN précise qu'elle s'appuie encore sur un moteur de navigateur et doit être conçue avec une amélioration progressive, car les API avancées ne sont pas présentes dans tous les navigateurs.
• Bureau. Electron empaquette Chromium et Node.js pour créer des applications de bureau avec JavaScript, HTML et CSS sous Windows, macOS et Linux ; sa documentation précise que le processus qui affiche l'interface n'a pas d'accès direct à Node.js, pour des raisons de sécurité. Tauri prend un autre chemin : il utilise le moteur web du système d'exploitation lui-même et un noyau en Rust, ce que sa documentation indique comme la raison pour laquelle ses applications sont très petites. Chaque choix a son coût : embarquer son propre moteur donne un comportement plus uniforme d'un système à l'autre ; dépendre de celui que fournit chacun économise de la taille, mais le moteur peut différer d'un système à l'autre et l'équipe doit résoudre des différences visuelles et de comportement (notre critère ; dans les deux cas, il faut tester sur chaque système d'exploitation que vous prenez en charge). Quand le bureau est réellement la réponse —imprimantes, lecteurs, balances, fichiers locaux— nous l'expliquons dans Votre application web ne suffit-elle plus ?.
• Mobile multiplateforme. React Native crée, à l'exécution, les vues natives d'Android et d'iOS à partir de composants React ; c'est pourquoi, selon sa documentation, les applications ont le même aspect et le même comportement que n'importe quelle autre. C'est une troisième voie entre le web mobile et deux développements natifs séparés.

Quand rien de tout cela n'est nécessaire

Si ce dont vous avez besoin est un blog ou une boutique standard, une plateforme de contenu déjà construite, rendue sur le serveur de manière classique, peut être une meilleure affaire que de monter une architecture sur mesure (notre critère). On choisit un paradigme lorsqu'un problème le justifie, non par goût de la nouveauté.

Comment choisir selon votre entreprise

Les coûts qui n'apparaissent pas dans la démonstration

• Coût d'exploitation. Le statique se sert avec un CDN ; le rendu côté serveur exige d'exécuter du code à chaque visite, sur un serveur propre ou chez un fournisseur, avec son coût à l'usage, sa montée en charge et sa supervision. Qu'un fournisseur administre l'infrastructure change qui l'exploite, pas le fait que quelqu'un doive la surveiller.
• Coût en talents. Chaque paradigme demande des compétences différentes. Un hybride bien fait exige que l'équipe comprenne ce qui s'exécute où ; sinon apparaissent des erreurs qui ne se produisent que « sur le serveur ». Et le volume compte : un outil que moins de personnes maîtrisent peut alléger l'infrastructure et renchérir le recrutement (notre critère).
• Coût de mesure. Choisir un paradigme n'améliore pas la performance à lui seul. Google définit ses trois signaux d'expérience au 75e centile des chargements, segmentés entre mobile et ordinateur : ils se mesurent avec de vrais utilisateurs, avant et après chaque décision.
• Coût de sécurité. Déplacer de la logique vers le serveur protège les secrets, mais un serveur exposé doit lui aussi être défendu ; déplacer de la logique vers le client la rend publique (nous le détaillons dans Ce que doit avoir un frontend professionnel).
• Coût de sortie. Le plus oublié : ce que coûte un changement d'avis. Un paradigme qui oblige à tout réécrire pour en changer est une décision coûteuse, même si elle paraît bon marché aujourd'hui.

Migrer sans tout réécrire

Réécrire de zéro est l'option qui coûte le plus et qui met le plus de temps à donner des résultats. L'alternative que nous recommandons comme critère est de migrer route par route, en commençant par celles qui pèsent le plus pour l'entreprise. Les sources le rendent possible : Next.js affirme qu'une SPA existante peut migrer sans être entièrement réécrite, qu'elle peut démarrer comme site statique ou même comme SPA stricte et ajouter progressivement des fonctions serveur, et propose des guides de migration incrémentale depuis d'autres environnements. La documentation de React signale qu'un framework couvre dès le départ ce qu'une application uniquement côté client résout à la main, comme éviter les cascades de requêtes.

Trois questions ordonnent une migration :

1. Quel écran vous coûte le plus aujourd'hui ? Des chargements lents sur celui qui génère des revenus, ou une page publique introuvable. Commencez par là, pas par le plus facile.
2. Que peut-on déplacer sans toucher à la logique métier ? La présentation se sépare généralement de la logique ; sinon, c'est la première découverte.
3. Comment saurez-vous que cela s'est amélioré ? Définissez d'abord le signal (performance, conversion, erreurs) et mesurez-le avec des données réelles.

Ce qu'il faut répondre avant de décider

Cinq questions auxquelles un comité peut répondre en une heure : qui arrive depuis un moteur de recherche et qui n'y arrive pas ? Quelles données ne peuvent pas vivre sur l'appareil ? Combien d'équipes touchent au même produit ? Quel canal utilise votre client le plus important ? Et, surtout, combien vous coûterait un changement d'architecture dans trois ans ?

Conclusion

La bonne architecture n'est pas la plus moderne : c'est celle que votre entreprise peut exploiter, mesurer et faire évoluer. Chez Hábil, nous aidons à la choisir avec un critère partagé et à construire le chemin de migration que votre équipe peut tenir.