Pourquoi votre site vitrine n'a probablement pas besoin d'un CMS

La plupart des sites vitrine que j’audite tournent sur WordPress. Vingt pages, un blog alimenté trois fois par an, un formulaire de contact. Et derrière : une base de données, un interpréteur PHP, une douzaine d’extensions, un constructeur de pages, un système de cache censé compenser la lenteur du reste.

C’est une architecture pensée pour un site de presse qui publie quarante articles par jour. Appliquée à une vitrine, elle produit surtout des effets secondaires.

Ce que coûte la surqualification

Un site dynamique reconstruit chaque page à chaque visite. Le serveur interroge la base, exécute le code, assemble le résultat, puis le met en cache pour éviter de recommencer. Quand tout va bien, on ne voit rien. Quand ça va mal — pic de trafic, extension qui traîne, crawler agressif — le serveur sature et la page ne s’affiche plus.

La surface d’attaque suit la même logique. Chaque extension est du code exécuté à chaque requête, maintenu par un tiers dont vous ne savez rien. Une vulnérabilité dans l’une d’elles suffit. Sur les sites que je reprends, la faille vient presque toujours d’une extension oubliée, pas du cœur applicatif.

Vient ensuite la dette de maintenance. Une version de PHP qui atteint sa fin de vie oblige à mettre à jour le thème, qui oblige à mettre à jour les extensions, dont certaines ne sont plus maintenues. J’ai vu cette chaîne bloquer des sites pendant des mois, jusqu’à ce que la mise à jour devienne un projet à part entière.

L’alternative : générer une fois, servir mille fois

Un site statique inverse la logique. Les pages sont assemblées une seule fois, au moment de la publication. Le visiteur reçoit un fichier HTML déjà prêt, servi depuis le point de présence le plus proche de lui.

Pas de base de données interrogée à la volée. Pas de code exécuté à la réception de la requête. Pas d’extension à maintenir. La page existe déjà : il n’y a plus qu’à la transmettre.

Les conséquences sont directes :

• Vitesse — le temps de réponse ne dépend plus de la charge du serveur mais de la distance réseau. Depuis les Antilles, cela se mesure.
• Résilience — un pic de trafic ne fait plus tomber le site. Servir un fichier statique dix mille fois ne coûte pratiquement rien.
• Surface d’attaque — il n’y a plus d’interface d’administration exposée, plus de base à injecter, plus d’extension à exploiter.
• Coût d’hébergement — souvent divisé par cinq ou dix, parfois nul selon le volume.

Quand cette approche ne convient pas

Elle n’est pas universelle, et je ne la recommande pas systématiquement.

Un site qui publie plusieurs fois par jour, avec une équipe éditoriale qui travaille en parallèle, tire un vrai bénéfice d’une interface de rédaction complète. Un catalogue de dix mille références avec des stocks qui bougent en temps réel n’a rien à faire en statique. Un espace client avec authentification et données personnalisées non plus.

La question n’est pas « statique ou dynamique » dans l’absolu. Elle est : qu’est-ce qui change, à quelle fréquence, et pour qui ?

Pour une vitrine mise à jour quelques fois par mois, la réponse est presque toujours la même. Le CMS résout un problème que vous n’avez pas, et vous facture ce service en performance, en sécurité et en temps de maintenance.

Et l’édition de contenu ?

C’est l’objection systématique, et elle est légitime. Personne ne veut ouvrir un éditeur de code pour corriger une faute de frappe.

Deux réponses existent aujourd’hui. Une interface d’édition légère peut se greffer sur un site statique : le rédacteur écrit dans un formulaire familier, et la publication déclenche une reconstruction automatique. Ou bien, quand une seule personne gère le contenu, l’édition directe en Markdown suffit largement — et se révèle souvent plus rapide qu’un constructeur de pages.

Dans les deux cas, la contrainte est plus faible qu’on ne l’imagine. Ce qui bloque, en général, ce n’est pas l’outil : c’est l’habitude.

Comment trancher

Trois questions suffisent à cadrer la décision.

À quelle fréquence le contenu change-t-il vraiment ? Pas la fréquence espérée au lancement — la fréquence observée sur les douze derniers mois.

Combien de personnes publient ? Une seule personne et une équipe de six n’appellent pas la même réponse.

Que payez-vous aujourd’hui pour la maintenance ? Hébergement, mises à jour, incidents, temps passé. Ce chiffre est souvent la véritable surprise de l’audit.

Si vos réponses sont « rarement », « une » et « plus que je ne pensais », la question mérite d’être posée sérieusement.