Créer un site web statique en 2024 : un grand oui !

English version

Les intelligences artificielles génératives nous forcent à réfléchir. Face au déferlement des contenus semi-débiles, il est temps de se poser les bonnes questions. Où va le web ? Sait-on encore faire des choses simples, avec des technologies éprouvées et sans flonflon ?

Dernière modification : 10/05/2025
Code source : repo

Make the web great again

Comme premier billet technique de ce blog, il nous a paru naturel de décrire la conception du blog lui-même. Histoire de changer un peu de la science des données, notre activité professionnelle et sujet de prédilection.

Le blog va évoluer au cours du temps.
Ce billet risque donc d'être déjà erroné.

Ceux qui nous lisaient lors de son lancement en 2024 ont constaté que la peinture n'était pas vraiment fraiche. Ceux qui lisent ce blog en 2067 pourront constater que si nous sucrons maintenant les fraises, nous étions sacrément bad ass et que le heavy metal reste foutrement à la mode.

UPDATE - les ajouts récents

Nous n'avons pas tout anticipé, et certains éléments manquaient. Les professionnels des sites webs se marrent déjà. Ah ah. Nous avons donc ajouté :

Ces fonctionnalités sont maintenant disponibles et écrites sous la forme de magnifiques verrues dans la base de code. Il conviendrait de refactoriser l'ensemble pour intégrer plus proprement ces ajouts. Antoine s'en chargera dès qu'il remettra les mains dans le code. Il adore faire le menage, surtout quand ça lui donnera une occasion de tout casser pour tout reconstruire.

Sobriété

Nous souhaitons construire un site avec une présentation minimaliste qui ne divertisse pas le lecteur du fond - qu'il soit présent ou non, ce n'est pas le sujet.

Ce site est uniquement composé de texte, de liens hypertextes et de documents à télécharger. On doit pouvoir afficher des images, bien sûr, même si nous le faisons rarement (une seule fois). Rien d'autre. Pas de commentaires. Pas de vidéo non plus. Encore moins de briques externes proposant des choses inutiles mais follement à la mode comme un agent conversationnel ou d'autres machins. Par conséquent, ce site n'a pas besoin d'être interactif.

Voici le cahier des charges. La solution technique est de construire un site statique. C'est-à-dire un site dont le contenu ne varie pas en fonction du lecteur, humain ou bot.

Un produit bien de chez nous

Début 2024, nous avons identifié de nombreux générateurs de sites statiques : Astro, Jekyll, Hugo. Mais … installer 600 Mo de dépendances obscures pour développer un site web statique, ça freine. Gérer des problèmes de versions en pagaille, en plus des inévitables emmerdes liées à Python, ça gave d'avance. Dans les 90s, on faisait sans ce bordel.

Et nous n'avons aucune envie de nous farcir des pages de documentation, même si elles sont bien écrites, ni de passer des heures sur Stack Overflow, et encore moins de lire du code pour trouver la bonne configuration qui marche. Rien de tout ceci n'est enthousiasmant. Pas envie.

En général, on n'en retire rien d'intelligent : tout ceci est trop de spécifique, rarement utile. OK le site tombe en marche, mais pourquoi ? D'autant plus que les technologies web ont cette fâcheuse tendance à devenir obsolètes dès qu'on regarde cinq minutes ailleurs.

Nous avons ainsi développé notre solution maison. Comme Ploum, ou comme le meilleur site du monde. Nous assumons gaiement de verser dans le plus pur syndrome NIH. Bien qu'à l'affut et prompt à réagir, nous sommes conscient que nous allons rencontrer d'inévitables UU tapies dans l'ombre prêtes à nous mordre au visage et à faire exploser nos scripts. Un beau programme.

Voici notre pari. Si des devs expérimentés, = des gens normaux qui ont déjà commis d'horribles erreurs en production, ne peuvent pas écrire simplement quelques pages HTML en 2024, alors le web a fortement régressé. Aucune autre possibilité n'est décemment envisageable.

Python

Un générateur de site statique n'est pas juste une simple page HTML. C'est un compilateur qui convertit quelque chose vers du HTML et du CSS. Autrement dit, c'est un programme qui prend du texte (dans un certain langage) en entrée et le transforme en HTML+CSS que le navigateur pourra alors afficher.

Pour écrire ce programme, nous avons choisi Python, langage vulgaire qui fait tout, mais mal et lentement. On sacrifie ainsi l'élégance à l'efficacité. Le but est d'avoir un site fonctionnel et maintenable, pas de définir une architecture web idéale à base de d'effets algébriques. Si nous avions le temps, nous l'aurions écrit en Haskell histoire que Thomas apprennent enfin ce magnifique langage.

Ah. Python. Sacré ophidien. Il fonctionne bien mais quel bordel pour la gestion des versions. Le gestionnaire d'environnement virtuel pipenv rapplique aussitôt et pyenv le rejoindra si les versions locales de Python ne correspondent pas. Nous avons commencé en 3.11 ; la dernière version en date (3.13.2) fonctionne.

pyenv est une bénédiction pour séparer facilement différents projets Python, et éviter de pourrir sa Debian avec des versions de bibliothèques incompatibles. On peut vraiment casser son OS comme ça. Ce guide nous a été utile. Nous avons convertis nos projets à pyproject pour spécifier les dépendances et limiter le boilerplate inutile ; et suivre les recommandations. Tout changera encore d'ici 18 mois, personne n'en doute une seconde.

Markdown

Code, billets, configuration, déploiement : du texte, rien que du texte. C'est plus pratique, ça se scripte et ça facilite la vie. Rappelons que le but de l'informatique est d'automatiser des actions chronophages, répétitives ou inintéressantes. Donc se faciliter la vie. CQFD.

Nous aurions pu choisir d'écrire nos billets en LaTeX, puis de les convertir automatiquement en HTML. Puisque les journées n'ont que 24 heures et que n'écrivons pas des articles scientifiques remplis d'équations, il faut être raisonnable : Markdown est un format très pratique et moins velu que l'honorable LaTeX, il fait le taf et Thomas a signifié qu'il préférerait largement se pendre de bon coeur que d'écrire à nouveau du LaTeX - une sorte de blocage psychologique, allez comprendre.

Il serait peu prudent d'écrire un compilateur Markdow vers HTML : l'honnête paquet markdown fait ça très bien. De plus, il a des extensions au cas bien improbable (en pratique p>0.9) où le format natif ne suffise plus.

I speak Wall Street English

Autant que possible, chaque page devait être traduite dans la langue des perfides. Nous avons une vie en dehors de l'informatique, et les progrès de la traduction automatique ont été fabuleux ces dernières années ; nous utilisons donc sans aucune vergogne les outils comme Deepl ou l'autre chat. Puisque le site est statique, cela implique de doubler tous les billets en Markdown et donc toutes les pages HTML. Pour les pages générales (comme l'index) et les différents composants (comme la barre de navigation), nous avons utilisé un dictionnaire de traduction pour chaque langue. Il y a encore une version par langue pour les pages générales, mais le but est de passer à une seule.

Dans les faits, on traduit peu.

Jinja

Une page web est constituée d'un en-tête, d'un pied de page, d'un menu de navigation et d'autres éléments que l'on retrouve inchangés à chaque page. Pour éviter de recopier à la main tous ces éléments (sans se tromper), on utilise le moteur de gabarit Jinja, plutôt répandu. On agrémente les gabarits avec plein de variables, par exemple pour obtenir la traduction des mots dans la langue affichée.

Là encore, c'est de la compilation : une surcouche HTML qui sera dépouillée par un programme adéquat. C'est sympa Jinja.

Jolie soupe

Les projets informatiques sont toujours plus complexes que prévus. On ne peut pas y échapper, c'est terrible. Cf plus haut.

Nous voulions insérer des liens vers la traduction d'un billet juste après son titre et avant son contenu. Problème : le titre du billet est écrit dans le même fichier Markdown que son contenu et tout est traduit d'un coup en HTML. Or, les liens sont engendrés par le générateur du blog : ils arrivent après. Notamment parce que le générateur vérifie si une traduction du billet existe. Bref, ça ne fonctionne pas d'un coup. Ce programme est vraiment mal conçu, il faudrait tout réécrire.

Il a donc fallu modifier le code HTML engendré par la traduction du Markdown en retirant le titre pour le déplacer à un autre endroit de la page finale. Avec le paquet Python BeautifulSoup, pensé pour travailler le HTML au corps.

CSS

Nous voulions éviter autant que possible le JavaScript, c'est fait. Puisque nous ne sommes pas tout à fait des barbares, nous avons opté pour CSS. Ce choix est ambitieux. Le CSS est une bête sauvage, un accumulateur de dette technique. Il a même été pensé comme ça, c'est dans son nom : une cascade de dépendances.

Le compilateur Sass, à défaut de le domestiquer, le tempère légèrement. Là aussi, par souci de légèreté, nous évitons (pour l'instant ?) les cadriciels comme Tailwind CSS. Thomas a ainsi eu l'opportunité d'apprendre ce truc, il est désormais dev web lui aussi.

Typographie

La typographie est un sujet important et souvent délaissé. Nous avons suivi les recommandations de Matthew Butterick, et, reconnaissons-le mollement, nous avons honteusement copié le style de son blog. Les polices utilisées sont IBM Plex, Charter et Terminal Grotesque.

Structure

Ce site est déjà multi-langues, multi-langages et multi-formats. Allez lire ce billet si vous voulez vraiment comprendre la différence entre ces trucs qu'on confond souvent.

Python d'un côté, le Markdown de l'autre, les gabarits Jinja ailleurs, le CSS autre part et du HTML partout. Et un peu de bash tout de même. Bref. Pour que chacun puisse retrouver ses petits, il faut disposer d'une structure de répertoires pertinente qui reflète le fonctionnement du générateur. On peut écrire du code propre au sein d'une structure infâme. Cela revient à lire un livre bien écrit mais dont les pages sont dans le désordre. Reconnaissez que c'est agaçant.

Le projet étant en cours, les fonctionnalités et, par conséquent, la structure va évoluer. Ou aurait du évoluer. Toutefois, certains répertoires s'imposent à force d'expérience, par exemple bin contenant des scripts utiles ou asset avec les données statiques.

GitLab

Pour éviter de se transmettre le code par mail ou pigeons voyageurs, nous avons déposé le code sur GitLab. Là. Libre à vous de reprendre le code et d'en faire ce que vous voudrez.

Stabilité

Ce site est en ligne depuis bientôt un an. Nous n'avons eu aucun souci sur le déploiement, la maintenance, l'ajout de fonctionnalités, les montées de versions etc. Objectif atteint pour l'instant.

ChatGPT, Mistral, DeepSeek

Aucun de ces outils n'a contribué à quoi que ce soit dans le code. Toutes les typos sont de nous.


A&T

Nous ne sommes toujours pas des machines. Nos textes sont pensés et écrits par des humains. Aucun texte n'est généré. Tout soutien sera le bienvenu.