Angular 19 SSR en production : ce que ça change, et les pièges

Ce site tourne sur Angular 19 en rendu serveur (SSR). Ce n'est pas une démonstration technologique : sans SSR, un site Angular dont le contenu vient d'une API est une page blanche pour la plupart des robots au moment où ils comptent. Ce qui suit est le retour d'expérience — ce que le SSR règle vraiment, ce qu'il coûte, les cinq pièges que nous avons rencontrés, et les cas où nous ne le recommandons pas.

Ce que c'est, en une phrase

En rendu client classique, le serveur envoie une page vide et un paquet de JavaScript ; le contenu apparaît après exécution. En rendu serveur, Node exécute l'application, produit le HTML complet, l'envoie, puis le navigateur « réhydrate » cette page pour la rendre interactive. Le visiteur — et le robot — reçoit du contenu au premier octet.

Le problème que ça règle

Un site vitrine dont les textes sont en base de données a besoin que ces textes soient dans le HTML servi. Trois choses en dépendent directement, et elles sont toutes mesurables :

• Les balises title et meta description, et les données structurées JSON-LD, présentes dans la réponse plutôt qu'ajoutées après coup.
• Les liens internes. Un lien qui n'existe qu'en JavaScript n'est pas un lien : Google indique explicitement qu'il ne suit de façon fiable qu'un élément <a> doté d'un href. Nous en avons fait l'expérience sur notre propre sélecteur de langue, qui était un <button> — nos pages françaises ne pointaient vers aucune page anglaise.
• Le premier affichage, sur les connexions et les terminaux qui ne sont pas ceux du développeur.

Ce que ça coûte réellement

Le coût principal n'est pas le développement, c'est l'hébergement — et c'est le point le plus mal anticipé au Maroc. Un site Angular en rendu client se dépose : des fichiers statiques, n'importe quel hébergement mutualisé fait l'affaire. Une application SSR a besoin d'un processus Node qui tourne en permanence, qu'il faut redémarrer, surveiller et mettre à jour.

Beaucoup d'offres mutualisées locales sont pensées pour Apache et PHP. Faire tourner un processus Node persistant y est parfois possible, parfois non, selon le plan — c'est une question à poser avant de choisir l'architecture, pas après la recette. Le deuxième coût est de compétence : il faut quelqu'un à qui un processus qui ne redémarre pas ne fait pas peur. Nos tarifs jour sont publiés sur la page tarifs ; nous ne donnons pas de prix d'hébergement ici parce qu'il dépend entièrement du plan retenu.

Cinq pièges, tous rencontrés sur ce site

1. ng serve ne teste pas votre serveur

C'est le piège le plus coûteux, parce qu'il donne l'illusion que tout fonctionne. Le middleware Express que vous écrivez dans server.ts — redirections, codes de statut, sitemap.xml, en-têtes de sécurité — n'est pas exécuté par ng serve. La seule façon de le tester est de construire, puis de lancer le serveur produit :

npm run build
node dist/frontend/server/server.mjs

Tant que vous n'avez pas fait cela, vous n'avez rien vérifié de votre couche serveur. Nous avons validé des redirections « qui marchaient » pendant des jours avant de comprendre qu'elles n'étaient jamais passées par le code concerné.

2. Les faux 404, ou comment fabriquer des pages fantômes

Quand un composant appelle l'API et qu'elle échoue, la tentation est d'afficher « contenu introuvable ». En SSR, cette page part avec un code HTTP 200 : pour un moteur, ce n'est pas une erreur, c'est une page pauvre à indexer. Un incident d'API de quelques minutes suffit à faire entrer des dizaines de fausses pages dans l'index, et elles y restent bien plus longtemps que l'incident.

La règle que nous appliquons depuis : un échec d'API n'est pas un « introuvable ». Le composant doit distinguer « l'API dit que ça n'existe pas » — un vrai 404 — de « l'API n'a pas répondu », qui doit produire un 503 avec un Retry-After, et surtout ne jamais être mis en cache.

3. Votre SSR est un client de votre propre API

Chaque page rendue côté serveur déclenche des appels à votre API, depuis une seule adresse IP. Notre limiteur de débit — écrit pour protéger l'API contre les abus — a commencé à bloquer notre propre serveur de rendu dès qu'un robot explorait plusieurs pages à la suite. Résultat : des pages incomplètes servies aux moteurs, et une cause introuvable côté frontend puisque le code était correct.

Deux corrections : relever la limite pour les routes publiques, et surtout exempter l'IP de sortie du serveur SSR. La deuxième est la vraie ; la première ne fait que déplacer le seuil.

4. Le build de production ne montre pas les données que vous croyez

Angular remplace les fichiers d'environnement selon la configuration de build. Un build de production pointe donc vers l'API de production — y compris quand vous lancez ce build sur votre machine. Nous avons vérifié pendant un moment des changements de contenu sur un serveur local qui, en réalité, affichait fidèlement les données de production. Pour vérifier du contenu local, il faut construire avec la configuration correspondante ; sinon vous testez le site de quelqu'un d'autre.

5. Cache HTML et en-têtes de sécurité ne s'entendent pas

Mettre en cache le HTML rendu est le gain de performance le plus simple. Mais si votre politique de sécurité utilise un nonce par réponse, un corps de page mis en cache contient un nonce périmé, et le navigateur bloque alors tous les scripts de la page. La solution est de stocker un marqueur dans le corps mis en cache et de le remplacer par la valeur réelle au moment de l'envoi, afin que l'en-tête et le corps portent toujours le même nonce.

Quand nous ne recommandons pas le SSR

• Une application derrière une authentification. Un back-office n'a aucun visiteur à référencer. Notre propre interface d'administration est volontairement en rendu client : le SSR n'y apporterait que de la complexité de déploiement.
• Un contenu entièrement statique. Si les textes ne viennent pas d'une base, la pré-génération au build est plus simple et plus robuste qu'un processus qui tourne.
• Sans personne pour exploiter Node. Un site SSR dont le processus tombe un vendredi soir est hors ligne, pas dégradé. Si cette astreinte n'existe pas, le rendu client est un choix plus honnête.

Ce que nous ferions différemment

Une seule chose, et elle aurait fait gagner des semaines : construire et servir le vrai serveur dès le premier jour, et faire de la vérification en HTTP — codes de statut, en-têtes, title servi, liens présents dans le HTML — une étape de la recette, au même titre que les tests unitaires. Les cinq pièges ci-dessus ont un point commun : aucun n'est visible depuis un navigateur en développement, et tous se voient en une commande curl sur le serveur construit.

Vous pouvez d'ailleurs vérifier ce site : le HTML servi contient les titres, les données structurées et les liens entre les versions française et anglaise.

Nous construisons des applications Angular et des plateformes métier depuis Casablanca — voir création de site web, plateformes métier et nos tarifs. Un projet en tête ? Demandez un devis.