Site statique, SSR ou CMS : que choisir pour une petite entreprise (mon cas réel)

Quand une entreprise me demande un site, avant même le design, il y a un choix qui pèsera pendant des années : site statique, rendu côté serveur (SSR) ou CMS ? Plutôt que de l'expliquer dans l'abstrait, je le raconte à travers le projet que je connais le mieux : ce site.

Les trois options en deux lignes

• Site statique : les pages sont des fichiers HTML prêts à l'emploi, générés une fois et déposés chez un hébergeur. Très rapide, peu coûteux, très difficile à attaquer. Mais chaque modification exige une nouvelle publication.
• SSR (server-side rendering) : un serveur génère la page à chaque requête, avec des données toujours à jour. Souple et excellent pour le SEO, mais il faut un serveur toujours allumé et quelqu'un pour le maintenir.
• CMS (WordPress ou un CMS headless) : le gérant modifie textes et articles depuis un tableau de bord, sans développeur. Pratique, mais cela implique des mises à jour, des plugins et une surface d'attaque à surveiller.

Mon cas : un site Angular publié en statique

Ce site est une application Angular avec le SSR configuré, un backend NestJS séparé avec MongoDB et un blog en sept langues dont les articles vivent dans la base de données. Sur le papier, c'est le cas idéal pour le SSR. En pratique, pour des raisons de coût et de simplicité, le frontend est compilé et publié sous forme de fichiers statiques sur un hébergement Plesk, tandis que le backend tourne sur un service séparé.

Ça fonctionne, mais j'ai découvert à mes dépens ce que ce choix implique.

1. Sans serveur, le SSR n'existe pas

Avec un déploiement statique, le rendu côté serveur ne s'exécute jamais : si une page n'est pas générée pendant le build, Google ne reçoit que la « coquille » vide de l'application. Quand je m'en suis aperçu, Google avait indexé 4 des 32 URL de mon sitemap, et aucun article : j'ai raconté toute l'enquête dans cet article. La solution a été le pré-rendu : générer au moment du build le HTML de chaque page, article par article et langue par langue.

2. Des centaines de pages à générer à chaque build

Chaque article existe en sept langues : il y a donc des centaines de pages à pré-rendre. Les premiers builds interrogeaient l'API de production pour chacune : la limite de requêtes se déclenchait et certaines pages étaient générées avec le message « article introuvable ». J'ai résolu le problème en téléchargeant tous les articles une seule fois avant le build, dans un fichier de cache où le pré-rendu va lire :

// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times

3. Chaque nouvel article exige une nouvelle publication

C'est le compromis le plus visible : quand je publie un article depuis le tableau de bord, le contenu est immédiatement disponible via l'API, mais la page HTML que lit Google n'existe qu'après le build suivant et l'envoi des fichiers. Pour un blog mis à jour de temps en temps, c'est acceptable ; pour un site d'actualités, non.

4. Les détails de l'hébergement comptent

Même avec les pages générées, Apache répondait à chacune par une redirection 301 : chaque page pré-rendue est un dossier contenant un index.html, et le serveur ajoutait la barre oblique finale à l'URL. La correction tenait en quelques lignes dans le .htaccess, mais sans une vérification avec curl -I je ne l'aurais jamais remarqué :

<IfModule mod_dir.c>
  DirectorySlash Off
</IfModule>

C'est justement à cause de ces compromis que je prépare le passage à un conteneur Node sur Plesk, avec un vrai SSR : la complexité était déjà dans le projet, autant l'exploiter jusqu'au bout.

Ce que je conseille à une petite entreprise

Mon site n'est pas un cas typique : c'est aussi un laboratoire. Pour une vraie entreprise, le choix se résume presque toujours à trois questions : à quelle fréquence les contenus changent, qui les met à jour et combien de pages sont nécessaires.

Pour beaucoup d'entreprises locales, les horaires, les avis et l'itinéraire comptent plus que le site lui-même : une fiche d'établissement Google bien tenue vaut souvent plus qu'une fonctionnalité de plus.

Les questions à se poser avant de choisir

1. Qui mettra à jour les contenus, et à quelle fréquence ? Si la réponse est « le gérant, chaque semaine », il faut un tableau de bord.
2. Quelle importance a Google ? Si le site vit de la recherche organique, chaque page doit arriver au robot sous forme de HTML complet : statique ou SSR, jamais une single page app sans pré-rendu.
3. Qui maintiendra le serveur ? Un SSR ou un CMS sans mises à jour vieillit mal ; un site statique peut rester intact pendant des années.
4. Jusqu'où peut-il grandir ? Commencer en statique et passer au SSR est possible, à condition de choisir une architecture qui le permet, comme cela a été mon cas avec Angular.

Les erreurs que je vois le plus souvent

• Un CMS lourd pour cinq pages qui ne changent jamais : des plugins à mettre à jour et des risques de sécurité sans aucun bénéfice.
• Une single page app sans pré-rendu pour un site qui doit être trouvé : agréable à utiliser, invisible pour les moteurs de recherche.
• Choisir le SSR sans budget pour le maintenir : un serveur doit être surveillé, mis à jour et payé chaque mois.

En résumé

Il n'existe pas de meilleure technologie dans l'absolu : il existe celle qui correspond à la façon dont les contenus sont mis à jour et à qui les gère. Pour la plupart des petites entreprises, un site statique bien conçu est le choix le plus solide ; un CMS a du sens quand le gérant veut de l'autonomie ; le SSR sert quand les contenus sont nombreux et changent souvent. Mon site m'a appris que chaque choix a un coût caché : l'important est de le connaître à l'avance. Si vous réfléchissez à un projet, écrivez-moi et partons de ces questions.