Pourquoi ce site n’a pas de backend

On me paie pour rendre les systèmes plus simples à exploiter. Ce serait étrange de construire mon propre site comme un système qui demande de l’exploitation.

Les contraintes étaient donc fixées avant la première ligne : hébergement gratuit, rapide sur un téléphone dans le train, impossible à casser à deux heures du matin, et encore lisible dans cinq ans. Ces contraintes éliminent un serveur.

Premier chargement : environ 70 Ko — 6,6 Ko de HTML, 9 Ko de CSS, deux fichiers de police. Aucun JavaScript.

Ce qui tourne

Astro génère du HTML statique. Une syntaxe de composants sans envoyer de framework au navigateur.
Collections de contenu : les articles sont des fichiers Markdown. Le build valide l’en-tête (titre, description, date, brouillon) et produit les pages et le flux RSS depuis la même source.
Cloudflare Workers en assets statiques : un push construit le site et le publie en périphérie. Pas de conteneur, pas de serveur.
Un Worker de douze lignes transforme www en redirection 301 vers l’apex ; tout le reste de ce qu’il sert est un fichier qui existait déjà.
Polices auto-hébergées : aucune requête vers un CDN de polices, aucun cookie tiers.
Mesure d’audience sans cookie : des pages vues, sans bandeau de consentement.

Pourquoi pas WordPress

WordPress est la bonne réponse bien plus souvent que les développeurs ne l’admettent. Il offre aux éditeurs une interface familière, une extension pour tout, et un vivier de gens capables de le maintenir. Quand cinq personnes publient chaque jour, un site statique est le mauvais outil.

Pour un auteur seul avec quelques pages, en revanche, WordPress apporte un runtime PHP, une base MySQL, une page de connexion exposée à internet, des extensions à mettre à jour et une facture d’hébergement qui suit. C’est un second système à maintenir pour taper du texte dans un formulaire plutôt que dans un fichier.

Pourquoi pas Next.js

Next ferait le travail. Il apporte aussi un runtime serveur, un framework de routage et une configuration de build pour des fonctionnalités que ce site n’a pas : pas d’authentification, pas de personnalisation par requête, pas de base de données. Astro envoie du HTML et une feuille de style — c’est tout le déploiement.

Pourquoi le blog est un dossier

src/content/blog/en et src/content/blog/fr. Chaque article est un fichier Markdown avec un en-tête. Le build les transforme en pages, et un titre manquant fait échouer le build au lieu de publier des métadonnées cassées. Pas de base de données, pas de panneau d’administration, rien à quoi se connecter.

Le compromis est réel : publier, c’est committer. C’est une exigence, pas une gêne — chaque article est versionné et écrit comme si quelqu’un allait le relire.

Bilingue sans service de traduction

L’anglais à /, le français à /fr/. Les deux sont écrits à la main ; rien n’est traduit automatiquement. Une page ne déclare hreflang que si l’autre langue existe vraiment. Déclarer une alternative qui renvoie une 404 est une erreur courante, et les moteurs de recherche apprennent à l’ignorer.

Les articles sont écrits dans une langue, pas dans les deux. Une traduction médiocre est pire qu’un manque honnête.

Quand je ne ferais pas ça

Cinquante éditeurs → WordPress ou Django CMS. Les éditeurs comptent plus que les temps de build.
Comptes, paiements, permissions → un vrai backend, et une base de données.
Collaboration temps réel → un serveur, et probablement une file d’attente.
Contenu qui change selon le visiteur → du rendu côté serveur.

La pile suit la contrainte. La plupart des sites que je construis pour des clients ne sont pas celui-ci : ils ont besoin d’une administration, d’une connexion, d’une intégration, d’un workflow. Celui-ci a besoin d’un nom de domaine.

Ce que ça coûte

Le domaine, une dizaine d’euros par an. L’hébergement, rien. Le build, moins d’une seconde. Il n’y a rien à patcher, rien à surveiller, et aucune facture qui grossit avec le trafic.

C’est le principe : le système le moins cher est celui qui ne tourne pas.