Philaire Le fil de Phil R.
FR EN ES
2026-02-08

Pourquoi un site statique

Ce site est statique. Pas de base de données, pas de PHP, pas de CMS qui vous demande de mettre à jour dix-sept plugins avant d'écrire une virgule. Des fichiers HTML, du CSS, et c'est tout. Et je vais vous expliquer pourquoi c'est exactement ce qu'il faut.

L'usine à gaz que personne n'a demandée

WordPress. Ah, WordPress. Le couteau suisse du web, disent ses fans. Sauf qu'un couteau suisse, en pratique, c'est un mauvais couteau, un mauvais tournevis et un tire-bouchon acceptable. WordPress propulse 40 % du web, et environ 40 % du web est lent, vulnérable et bourré de popups « Accepter les cookies ». Coïncidence ? (tousse)

Pour un blog personnel (quelques billets, quelques images, zéro commentaire parce que soyons honnêtes personne ne commente), WordPress, c'est prendre un semi-remorque pour aller chercher le pain. Avec la clim, le GPS et un copilote.

Et les plateformes hébergées, alors ? Medium, Substack, tout ça ? Elles règlent le problème de la maintenance, d'accord. Mais en échange, votre contenu vit chez quelqu'un d'autre. Soumis à ses conditions, ses pivots stratégiques (parce qu'il faut bien lever un tour de table), et sa fermeture éventuelle. Vous n'êtes pas propriétaire. Vous êtes locataire. Et le bail est résiliable sans préavis.

JavaScript, non merci

Il faut qu'on parle de JavaScript.

J'ai une relation avec JavaScript qu'on pourrait qualifier de « conflictuelle ». Dans le sens où JavaScript me donne des boutons et où je le lui rends bien. Un site web, en 2026, c'est en moyenne 2 Mo de JS avant d'afficher le moindre paragraphe. Deux mégaoctets. Pour du texte. On a envoyé des gens sur la Lune avec moins de mémoire que ce qu'il faut pour charger un article de blog sur un framework React.

Et pendant ce temps, votre vieux portable rame, votre lecteur d'écran s'étrangle, votre forfait 4G fond comme neige au soleil, et la moitié de la planète avec une connexion un peu lente se retrouve devant un spinner éternel. Tout ça pour afficher des mots. Des mots !

Je veux un web accessible. Qui marche sur un téléphone à 80 euros comme sur un MacBook Pro. Qui se lit avec un lecteur d'écran sans que l'utilisateur ait envie de jeter son ordinateur par la fenêtre. Qui se charge en une seconde sur une connexion ADSL de campagne. Qui ne demande pas à votre navigateur de compiler un framework entier pour vous montrer un paragraphe.

Du HTML sémantique, du CSS raisonnable, et quasiment zéro JavaScript. Ce site compte ses <script> sur les doigts d'une main, et encore, d'une main de Simpson. À l'heure où j'écris, un seul, sur une seule page, pour un schéma interactif, parce que parfois il faut bien. Tout le reste, c'est du HTML pur. Essayez d'inspecter la source si vous ne me croyez pas. C'est la page la plus ennuyeuse que vous verrez de la journée, et j'en suis fier.

De Pelican à Zola, en passant par Nikola

Mais un site statique, ça se génère. Et là, il faut choisir son outil. J'ai un peu vadrouillé.

Pelican d'abord. Python, communauté sympathique, ça faisait le boulot. Jusqu'au jour où j'ai voulu un truc un peu custom sur les templates, et où je me suis retrouvé à debugger du Jinja2 à 23 heures en me demandant ce que j'avais fait pour mériter ça. L'écosystème de thèmes est... disons vintage. Et la gestion multilingue relevait davantage de l'acrobatie que de la fonctionnalité.

Nikola ensuite. Python aussi, plus complet, plus de fonctionnalités. Trop de fonctionnalités, en fait. Nikola fait du blog, du site, de la galerie photo, du Jupyter Notebook, du microformat et probablement du café si on lui demande poliment. Pour mon besoin (des fichiers Markdown, trois langues, du HTML propre en sortie), c'était le semi-remorque, encore une fois.

Et puis Zola. Un seul binaire. Pas de dépendances. Pas de pip install qui casse tout, pas de virtualenv, pas de Node.js (frissons). On télécharge, on lance, ça marche. Le moteur de templates est intégré, le multilingue est natif, la compilation est instantanée (merci Rust). C'est rapide, c'est sobre, c'est exactement ce qu'il faut et rien de plus.

La beauté du truc qui ne fait rien

Un générateur de site statique prend des fichiers Markdown et produit du HTML. Point. Pas de serveur qui interprète quoi que ce soit. Pas de base de données qui attend sagement qu'un script kiddie vienne la chatouiller.

Ce que ça donne, concrètement :

Écrire, pas administrer

Écrire un billet sur ce site, c'est : ouvrir un fichier texte, taper, sauvegarder. Pas de tableau de bord. Pas de formulaire. Pas de connexion internet pour rédiger (le wifi du TGV, on en parle ?). Le contenu est en Markdown, un format lisible à l'œil nu, convertible vers n'importe quoi.

Et si Zola disparaît demain ? (C'est du logiciel libre, je ne suis pas vraiment inquiet, mais jouons le jeu.) Les fichiers Markdown restent. Je change de générateur en une après-midi. Hugo, Eleventy, un script Bash fait maison un dimanche de pluie… le contenu s'en fiche.

Essayez de migrer un WordPress de dix ans vers autre chose. Non, sérieusement, essayez. Je vous attends. (bruits de café qu'on se ressert)

Le bon outil, le bon usage

Soyons honnêtes : un site statique ne fait pas tout. Si vous avez besoin de comptes utilisateurs, de commentaires en temps réel, d'un panier d'achat ou d'une application web, il vous faut du dynamique, et c'est normal. Je ne suis pas en train de dire que toute la tech moderne est inutile (juste une bonne partie, mais c'est un autre billet).

Mais pour un blog ? Un portfolio ? Une documentation ? Un site personnel où l'on raconte sa vie, ses jeux et ses opinions plus ou moins fondées ? Le statique est plus rapide, plus sûr, plus simple et plus durable que tout le reste.

Moins de technologie, plus de contenu. Et le contenu, c'est ce qui reste quand les frameworks ont disparu.

Les trois monuments

J'ai découvert ces sites à peu près en même temps que CrunchBang Linux. Pour ceux qui n'ont pas connu : CrunchBang (#!), c'était une Debian avec Openbox, un fond d'écran gris, un menu au clic droit, et rien d'autre. Ça démarrait en trois secondes sur un PC de 2005 et ça faisait tout ce qu'on lui demandait sans broncher. Le jour où j'ai installé #! sur un vieux portable que je pensais bon pour la déchetterie, et que ce truc a ressuscité comme si de rien n'était… j'ai compris qu'on m'avait menti pendant des années sur ce dont un ordinateur avait « besoin » pour fonctionner.

C'est exactement à cette époque que je suis tombé sur ces trois sites (âmes sensibles au vocabulaire fleuri, vous êtes prévenus) :

motherfuckingwebsite.com, le manifeste originel. Une page HTML brute, sans CSS, sans JS, sans image, sans rien. Du texte noir sur fond blanc. Et un argumentaire imparable : votre site est responsive ? Le mien aussi, par défaut, parce que je n'ai rien fait pour le casser. Ça charge vite ? Évidemment, il n'y a rien à charger. C'est la gifle que mérite chaque développeur front-end qui a un jour écrit npm install pour afficher du texte.

bettermotherfuckingwebsite.com, la réponse. Même philosophie, mais avec un tout petit peu de CSS : une largeur max, une police lisible, des marges correctes. Le message : on n'est pas obligé de choisir entre « moche et fonctionnel » et « joli et inutilisable ». Quelques lignes de CSS suffisent. Pas un framework, pas un préprocesseur, pas un bundler, juste du CSS écrit par un être humain qui se souvient à quoi ça sert.

thebestmotherfucking.website, le troisième acte. Un cran au-dessus en design (thème sombre, typographie soignée), toujours sans JS, toujours léger, toujours accessible. La preuve que minimalisme et esthétique ne sont pas incompatibles. On peut faire beau sans faire lourd.

Ces trois sites, c'est exactement la même leçon que CrunchBang m'avait apprise sur le bureau : la plupart de ce qu'on empile sur nos machines et nos pages web n'est pas là pour l'utilisateur. C'est là pour le développeur, pour le designer, pour le chef de projet, pour la démo au client. L'utilisateur, lui, il veut lire un texte. Et pour lire un texte, il n'a besoin de rien de tout ça.